Security Requirements Analysis Report
Comprehensive Security Analysis with Interactive Dashboard
Generated: 2025-11-20 11:21:45 Report Version: 2.0 - Comprehensive Security Analysis
1. Executive Summary
This section provides a high-level overview of the security requirements analysis, presenting key findings, validation results, and an interactive dashboard for stakeholders and decision-makers. The executive summary enables rapid comprehension of the security posture, critical risks, control coverage, and compliance status without requiring detailed technical knowledge.
1.1. Purpose and Scope
Purpose
This document presents a comprehensive security requirements analysis for the proposed application, systematically mapping high-level business requirements to specific, actionable security controls aligned with multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. The analysis provides a complete security requirements specification that guides secure system design, implementation, and verification.
Scope
This analysis encompasses all functional requirements provided, delivering comprehensive coverage across multiple security domains:
- Requirements Analysis: Systematic decomposition and security-relevant extraction from business requirements
- Stakeholder Analysis: Identification of stakeholders, trust boundaries, and security responsibilities
- Threat Modeling: Systematic identification and assessment of security threats using STRIDE methodology
- Security Control Mapping: Mapping requirements to multi-standard security controls (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed implementation guidance
- Compliance Requirements: Identification of regulatory and legal compliance obligations
- Architectural Security: Security architecture recommendations and design patterns
- Implementation Planning: Prioritized, phased implementation roadmap
- Verification Strategies: Testing and validation approaches for security controls
The analysis provides both strategic guidance for security planning and tactical details for implementation teams.
1.2. Key Findings
This section summarizes the most critical results from the security requirements analysis, providing executives and stakeholders with immediate insight into the security posture and validation status.
Analysis Metrics
- Validation Score: 0.84/1.0
- Validation Status: ✅ Passed
- Analysis Iterations: 1
- Requirements Analyzed: 18
Application Summary
A responsive web application for employees to record daily and weekly working hours, request and track holidays, and submit timesheets for managerial approval; managers can review, approve/reject (or delegate approvals), view team timesheet and leave history, and administrators configure system-wide rules, user management, and audit logs, while authentication is provided via Azure SSO and access controlled by organizational team hierarchy.
The validation score reflects the quality and completeness of the security requirements across five dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. A score of 0.8 or higher indicates that the requirements are ready for implementation, while scores below this threshold may require refinement before proceeding.
1.3. Security Overview Dashboard
This interactive dashboard provides executive-level visualization of key security metrics and trends, enabling rapid assessment of the security posture through intuitive charts and data visualizations. The dashboard presents critical information across multiple dimensions: risk distribution, security control coverage, compliance status, implementation progress, and data quality metrics. For optimal viewing experience, render this document with Quarto to enable interactive chart functionality, allowing stakeholders to explore data dynamically and drill down into specific areas of interest.
Top 5 Highest Risks:
THR-003 (Critical) - Timesheet Entry / Frontend & API - Category: Tampering - Likelihood: 4 | Impact: 4 - Description: A malicious user manipulates client-side data (e.g., via browser devtools, intercepted requests, or a scripted client) to submit falsified timesheet hours, change project/task codes, or bypass require
THR-012 (High) - Integration & External Services (Email) - Category: Spoofing - Likelihood: 4 | Impact: 3 - Description: Attackers send spoofed emails resembling system notifications (approval requests or delegation changes) to trick users into clicking malicious links or divulging credentials.
THR-001 (High) - Integration & External Services / Frontend / Application Services (Azure AD SSO tokens) - Category: Spoofing - Likelihood: 3 | Impact: 4 - Description: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, token theft, or compromised device) and impersonates employees/managers to submit or approve timesheets, view other users’ d
THR-004 (High) - Application Services (Approval API) - Category: Tampering - Likelihood: 3 | Impact: 4 - Description: An attacker modifies API requests (parameter tampering) to set approval fields (e.g., approved=true) or change timesheet status without proper authorization checks, enabling unauthorized approvals or
THR-005 (High) - Data Storage / Operational Services (Audit logs) - Category: Repudiation - Likelihood: 3 | Impact: 4 - Description: Insufficient or modifiable audit logging allows users (or attackers) to deny actions or to remove traces of malicious changes (e.g., approvals, delegation changes) so incidents cannot be proven.
Coverage Metrics:
- Total Security Controls Mapped: 54
- OWASP ASVS: 18 controls
- NIST SP 800-53: 19 controls
- ISO 27001: 17 controls
- Requirements with Security Control Mapping: 94.4% (17/18)
- Average Controls per Requirement: 3.0
- Critical Controls: 21 (38.9% of total)
- Requirements with Verification: 100.0% (18/18)
- Recommended ASVS Level: L2 (Standard)
Compliance Summary:
- ⚠️ OWASP ASVS: In Progress (Next Audit: N/A)
- ⚠️ NIST SP 800-53: In Progress (Next Audit: N/A)
- ⚠️ ISO 27001: In Progress (Next Audit: N/A)
Implementation Timeline (Projected):
- Phase 1 (Critical/High): 100% projected completion (Weeks 1-8)
- Phase 2 (Medium): 100% projected completion (Weeks 9-16)
- Phase 3 (Low/Ongoing): Continuous improvement and monitoring
Note: Timeline is based on priority-based planning and assumes steady implementation progress.
Validation Metrics:
Overall Validation Score: ✅ 0.84/1.0
Dimension Scores:
- ✅ Completeness: 0.80
- ✅ Consistency: 0.90
- ✅ Correctness: 0.90
- ⚠️ Implementability: 0.75
- ✅ Alignment: 0.85
Traceability Matrix:
- Total Requirements: 18
- Linked to Threats: 17 (94.4%)
- Mapped to Security Controls: 17 (94.4%)
- With Verification: 18 (100.0%)
Data Quality: ✅ Excellent
2. Requirements Understanding
This section presents a comprehensive analysis of the functional requirements, extracting security-relevant information and establishing the foundation for the security requirements specification. Understanding the functional requirements is essential for identifying security implications, data sensitivity, trust boundaries, and security-critical components. This analysis transforms business requirements into security-aware specifications that inform threat modeling, control selection, and compliance assessment.
2.1. High-Level Requirements Analysis
The following high-level functional requirements have been identified and analyzed for security implications:
- Role-based access control with Employee, Manager, Delegate, and Administrator roles
- Azure SSO integration for authentication and single sign-on
- User management and team hierarchy mapping (assign managers, teams, delegates)
- Daily and weekly timesheet entry supporting multiple projects/tasks
- Save draft timesheets with validation preventing submission until required fields completed
- Timesheet submission workflow with submission timestamp and read-only state after submission
- Approval/rejection workflow for managers and delegates, including comments and logging
- Manager delegation with start/end dates, scope of permissions, revocation, and notifications
- Holiday and leave request management with leave balance tracking and manager approval
- Public holiday preload and auto-application to timesheets
- Business rules enforcement: configurable workweek, min/max hours, working patterns
- Notifications via email for reminders, approval requests, approvals/rejections, and delegation changes
- Reporting: weekly, monthly, and custom time reports for employees and managers
- Audit logging of timesheet lifecycle events, approvals/rejections, delegation changes, and admin amendments
- Administrator capabilities to configure system settings, working patterns, public holidays, and amend submitted timesheets
- Responsive and accessible UI compliant with WCAG guidelines
- Data access restrictions based on team hierarchy and least-privilege principles
- Data retention, encryption, and export capabilities to support compliance and integrations with payroll/HR
2.2. Detailed Requirements Breakdown
| Req ID | Requirement | Business Category | Security Sensitivity | Data Classification |
|---|---|---|---|---|
| REQ-001 | Role-based access control with Employee, Manager, … | User Management / Authorization | High | Confidential |
| REQ-002 | Integrate with Azure SSO for authentication and su… | Authentication | High | Internal |
| REQ-003 | User management and team hierarchy mapping to assi… | User Management / Data Management | High | Confidential |
| REQ-004 | Daily and weekly timesheet entry supporting multip… | Timesheet Management / Data Entry | Medium | Confidential |
| REQ-005 | Save draft timesheets locally/server-side and prev… | Data Validation / UX | Low | Internal |
| REQ-006 | Timesheet submission workflow that records submiss… | Approval Workflow / Audit | High | Confidential |
| REQ-007 | Managers and assigned delegates can approve or rej… | Approval Workflow / Audit | High | Confidential |
| REQ-008 | Manager delegation capabilities: assign delegates … | Delegation / Authorization | High | Confidential |
| REQ-009 | Holiday and leave request management: request holi… | Leave Management / Data Management | Medium | Confidential |
| REQ-010 | Public holiday preload and automatic application t… | Configuration / Leave Management | Low | Internal |
| REQ-011 | Business rules engine to configure workweek, worki… | Business Rules / Data Validation | Medium | Internal |
| REQ-012 | Email notifications for timesheet submission remin… | Notifications / Communications | Low | Internal |
| REQ-013 | Reporting: generate weekly, monthly, and custom re… | Reporting / Analytics | Medium | Confidential |
| REQ-014 | Comprehensive audit logging capturing creation/upd… | Audit & Compliance | High | Restricted |
| REQ-015 | Administrator capabilities to configure system set… | Administration / Governance | High | Confidential |
| REQ-016 | Responsive UI supporting desktop, tablet, and mobi… | UI/UX / Accessibility | Low | Public |
| REQ-017 | Enforce data access restrictions based on team hie… | Authorization / Data Access Control | High | Confidential |
| REQ-018 | Data retention, encryption at rest and in transit,… | Data Protection / Integration | High | Confidential |
2.3. Security Context and Regulatory Obligations
Applicable regulations and compliance considerations: GDPR (and relevant national data protection laws) for personal data processing and data subject rights (access, rectification, erasure); local employment and payroll regulations for recordkeeping; data residency requirements where organizational policy or law mandates storage in a specific jurisdiction; ISO 27001 / SOC 2 good practices for information security controls; organizational policies enforced via Azure AD (MFA/conditional access); retention and audit requirements for payroll records; encryption in transit (TLS 1.2+/TLS 1.3) and at rest (AES-256 or equivalent); logging and tamper-evident audit trails for non-repudiation; least privilege and role-based access controls; secure software development lifecycle (SAST/DAST) and vulnerability management; secure email handling (avoid leaking PII in notifications), and contractual/privacy notices to satisfy lawful basis for processing employee personal data.
2.4. Assumptions
- System will be cloud-hosted (e.g., Azure) and accessible over the internet
- Organization uses Azure Active Directory for identity and will provide required SSO configuration and claims
- Users have regular internet access and modern browsers on desktop/tablet/mobile
- Email delivery (SMTP or transactional email service) will be provided by the organization or cloud provider
- Team membership, manager relationships, and organizational hierarchy can be synchronized from the identity provider or HR system
- Payroll/HR integrations are out-of-scope initially but required in future (APIs available)
- Time zones and locale differences must be supported for multi-region deployments
- Administrators will define business rules (working patterns, public holidays, min/max hours) during configuration
- Retention and deletion policies will be defined by the organization based on legal and business requirements
2.5. Constraints
- Must integrate with Azure SSO (Azure AD) as the authentication mechanism
- UI must be responsive and comply with WCAG accessibility guidelines
- Data residency or jurisdictional storage requirements may restrict cloud region selection
- Limited initial integrations (payroll/HR) — exported files/APIs should be provided for later integration
- Administrators must be able to amend submitted timesheets; such actions must be auditable and cannot be disabled entirely
- System must enforce least-privilege access controlled by team hierarchy; cross-team access requires explicit admin configuration
- Audit logs must be retained according to organizational policy and protected against tampering (write-once or immutable storage preferred)
- Notifications must not contain sensitive personal data (e.g., detailed hours) to avoid email leakage; links to the system should require authentication
- Performance: system should support expected concurrent user load (to be specified by stakeholders) and scale in cloud environment
- Compliance testing (GDPR, security controls) must be completed prior to production rollout
3. Stakeholder Analysis
This section identifies and analyzes all stakeholders involved in or affected by the system, including users, administrators, external partners, and regulatory bodies. Stakeholder analysis establishes trust boundaries, defines security responsibilities, and identifies potential security concerns from different stakeholder perspectives. Understanding stakeholder relationships and trust boundaries is critical for designing appropriate access controls, authentication mechanisms, and data protection measures.
3.1. Identified Stakeholders and User Personas
| Role | Privilege Level | Trust Level | Key Security Concerns |
|---|---|---|---|
| Employee | User | Partially Trusted | Unauthorized access to sensitive timesheet data, submission of fraudulent timesheets, identity theft. |
| Manager | User | Trusted | Mismanagement of team data, unauthorized approval of timesheets, phishing attacks targeting credentials. |
| Delegate | User | Partially Trusted | Abuse of delegated powers, unauthorized access to team members’ timesheets, phishing attacks. |
| Administrator | Admin | Trusted | Privilege escalation by malicious insiders, unauthorized changes to system configurations, data breaches. |
| External HR System | Service Account | Partially Trusted | Insecure API integration exposing sensitive employee data, inadequate authentication mechanisms. |
| Email Notification Service | Service Account | Untrusted | Potential for email spoofing, unauthorized access to notification logs, interception of sensitive information. |
| API Layer | Service Account | Trusted | Exposure of data through API vulnerabilities, unauthorized access to system functions. |
3.2. Trust Model
Trust boundaries are established at the user interface, API layer, and database levels. Security mechanisms enforcing these boundaries include Azure AD SSO for authentication, role-based access control (RBAC) to ensure users can only access data and functionalities pertinent to their roles, and network segmentation to mitigate risks of unauthorized access. Employees can access their own timesheets and submit hours, while Managers have access to approve or reject timesheets and view team data. Delegates can perform management tasks during designated periods but have restricted access outside their authorization. Administrators have comprehensive management capabilities but are monitored through audit logs to prevent misuse. The principle of least privilege is implemented by granting users the minimum access necessary to perform their responsibilities, thereby reducing the risk of data exposure and privilege escalation. This includes limiting access to only those functions and data required for each role, ensuring that no user can exceed their assigned authority.
4. System Architecture Analysis
4.1. Architectural Overview
A cloud-hosted, responsive web application composed of a client SPA and mobile responsive UI that talk to a central API layer protected by Azure AD SSO and an edge layer (CDN/WAF). The API layer implements core timesheet, approval, delegation, holiday, notification, reporting, and business-rule services; it uses a relational database for primary domain data (timesheets, users, audit), blob storage for attachments and immutable audit retention, a cache for performance, and an async queue for notifications and reporting jobs. External integrations include Azure AD for authentication, an email/transactional service for notifications, and optional HR/payroll APIs for exports. Access and data visibility are enforced by RBAC driven by team hierarchy and runtime business rules, and all lifecycle events are logged to tamper-resistant audit storage.
4.2. Architecture Diagram
4.3. Component Breakdown
| Component | Responsibility | Security Criticality | External Dependencies |
|---|---|---|---|
| Frontend Layer | Deliver the responsive SPA and admin UI … | Medium | CDN, Browser platform and client OS |
| Edge Layer | Public perimeter with CDN for static con… | High | CDN provider, WAF/DDoS protection (cloud provider) |
| Application Services | Core domain services including API gatew… | Critical | Azure AD (Auth), Email/Transactional service |
| Data Storage | Persist domain data in a relational stor… | Critical | Cloud RDBMS, Cloud Blob Storage |
| Integration & External Services | Third-party and org services for authent… | High | Azure AD SSO, Email/Transactional provider (SMTP/API) |
| Operational Services | Monitoring, logging, alerting, backup, a… | High | Cloud monitoring/logging service, Immutable storage or log analytics |
4.4. Data Flow Analysis
Users interact via the SPA or mobile UI served through the CDN/WAF. The frontend authenticates users via Azure AD SSO (OIDC) and obtains tokens to call the Core API. The API enforces RBAC and team-hierarchy checks, validates data against the Business Rules Engine, persists timesheets and audit events to the relational DB, writes immutable audit copies and attachments to blob storage, and publishes async events to a message queue. The Notification Service consumes queue events and sends emails via a transactional email provider (without PII in body). Reporting jobs read aggregated data from the DB (and cache) or consume queued events to generate exports. HR/payroll integration uses secure API exports or scheduled file exports. All data in transit is TLS encrypted and data at rest is encrypted by the storage services.
4.5. Attack Surface Analysis
Primary entry points: client UI (browser/mobile) and public API endpoints (risk: High). Authentication depends on Azure AD SSO — compromise of identity tokens or misconfiguration of federation/claims is High risk. Exposed APIs: timesheet CRUD, submission/approval endpoints, admin/config APIs — these must enforce strong RBAC and input validation (risk: High). Edge-layer risks include DDoS and injection attacks mitigated by CDN/WAF (risk: Medium). Integration points (email service, HR/payroll API) present risk if credentials leaked or if outputs include PII (risk: Medium). The data tier is high value; DB credentials or blob access compromise could expose confidential data (risk: Critical). Additional risks: improper delegation logic or faulty team-hierarchy sync may enable unauthorized access (risk: High); email notifications leaking detailed PII — mitigate by sending minimal metadata with links; audit logging integrity threats require immutable storage and restricted admin access. Recommended mitigations: enforce Azure AD conditional access and MFA, strict RBAC and runtime claim checks, input/output validation, WAF and rate limiting, network segmentation, encryption in transit and at rest, immutable audit storage, regular SAST/DAST scans, and periodic access reviews and delegation audits.
5. Threat Modeling
This section presents a comprehensive threat analysis of the system architecture and functional requirements. Threat modeling systematically identifies potential security vulnerabilities and attack vectors, enabling proactive risk mitigation through the application of appropriate security controls.
5.1. Threat Modeling Methodology
This analysis employs the STRIDE threat modeling methodology, a systematic framework developed by Microsoft for identifying security threats across six categories:
- Spoofing Identity: Threats involving impersonation of users or systems
- Tampering with Data: Threats involving unauthorized modification of data or system components
- Repudiation: Threats where users deny performing actions (lack of non-repudiation)
- Information Disclosure: Threats involving unauthorized access to sensitive information
- Denial of Service: Threats causing disruption or unavailability of system services
- Elevation of Privilege: Threats allowing unauthorized access to privileged functions
For each identified threat, the analysis evaluates likelihood (attack complexity and exposure) and impact (potential damage to confidentiality, integrity, or availability) to determine overall risk level. The methodology ensures comprehensive coverage of security concerns across all system components and interfaces.
5.2. Threat Analysis and Risk Assessment
5.2.1. Threat Overview
The following table provides a quick reference of all identified threats. Detailed analysis including descriptions, mitigation strategies, and residual risk assessment (where available) is provided in the section below.
| Threat ID | Component | Category | Risk Level | Likelihood | Impact |
|---|---|---|---|---|---|
| THR-003 | Timesheet Entry / Frontend & API | Tampering | Critical | High | High |
| THR-001 | Integration & External Services / Frontend / Application Services (Azure AD SSO tokens) | Spoofing | High | Medium | High |
| THR-004 | Application Services (Approval API) | Tampering | High | Medium | High |
| THR-005 | Data Storage / Operational Services (Audit logs) | Repudiation | High | Medium | High |
| THR-007 | Data Storage (Relational DB / Blobs) | Information Disclosure | High | Medium | High |
| THR-008 | Application Services (APIs enforcing team hierarchy) | Information Disclosure | High | Medium | High |
| THR-009 | Application Services / Operational Services (Administrator accounts) | Elevation of Privilege | High | Medium | High |
| THR-010 | Edge Layer (CDN/WAF/DDoS) | Denial of Service | High | Medium | High |
| THR-012 | Integration & External Services (Email) | Spoofing | High | High | Medium |
| THR-013 | Frontend Layer (SPA) / Application Services (API responses) | Information Disclosure | High | Medium | High |
| THR-019 | Manager Delegation / Data Storage | Spoofing | High | Medium | High |
| THR-021 | Application Services (API/DB) | Tampering | High | Medium | High |
| THR-022 | Data Storage (Backups / Cloud storage) | Information Disclosure | High | Medium | High |
| THR-024 | Application Services (Authorization / RBAC) | Elevation of Privilege | High | Medium | High |
| THR-026 | Edge Layer / Frontend (CDN delivered JS) | Tampering | High | Medium | High |
| THR-027 | Edge Layer / Application Services (TLS termination) | Information Disclosure | High | Low | High |
| THR-029 | Operational Services / Data Storage (Insider threat) | Denial of Service | High | Low | High |
| THR-030 | Integration & Data Storage (Cloud IAM & managed identities) | Elevation of Privilege | High | Medium | High |
| THR-002 | Frontend Layer / Application Services (JWT/session handling) | Spoofing | Medium | Medium | Medium |
| THR-006 | Integration & External Services (Email notifications) | Information Disclosure | Medium | Medium | Medium |
| THR-011 | Application Services / Message Queue | Denial of Service | Medium | Medium | Medium |
| THR-014 | Data Storage (Blob attachments) | Tampering | Medium | Low | Medium |
| THR-015 | Application Services / Operational Services (Audit & Approval) | Repudiation | Medium | Medium | Medium |
| THR-016 | Manager Delegation (Application Services) | Elevation of Privilege | Medium | Medium | Medium |
| THR-017 | Application Services (Business rules engine) | Tampering | Medium | Medium | Medium |
| THR-018 | Operational Services (Monitoring & Logs) | Information Disclosure | Medium | Medium | Medium |
| THR-023 | Application Services / Notifications (Message Queue) | Denial of Service | Medium | Medium | Medium |
| THR-025 | Frontend Layer / Application Services (CSRF vector) | Tampering | Medium | Medium | Medium |
| THR-028 | Integration & External Services (Transactional Email provider) | Repudiation | Medium | Low | Medium |
| THR-020 | Integration & External Services (Public holiday feeds) | Information Disclosure | Low | Low | Low |
Total Threats Identified: 30
5.2.2. Detailed Threat Analysis
This section provides comprehensive analysis of each identified threat, including descriptions, mitigation strategies, and residual risk assessment (where controls have been evaluated). Threats are organized by risk level for prioritized review.
Critical Risk Threats
THR-003 - Timesheet Entry / Frontend & API
- Category: Tampering
- Likelihood: High | Impact: High
- Initial Risk Level: Critical
- Description: A malicious user manipulates client-side data (e.g., via browser devtools, intercepted requests, or a scripted client) to submit falsified timesheet hours, change project/task codes, or bypass required-fields checks resulting in fraudulent payroll/exported data.
- Mitigation Strategy: Enforce all validation and business rules server-side (required fields, min/max hours, project permissions). Implement strong authorization checks for project/task assignment. Log all changes with user identity and timestamps. Use anomaly detection on submitted hours and require manager validation for outliers.
- Controls Applied: Server-side validation, Business rules enforcement, RBAC, Audit logging, Anomaly detection
- Control Effectiveness: Medium
- Residual Risk Level: High
- Status: ⚠️ Requires Review
High Risk Threats
THR-001 - Integration & External Services / Frontend / Application Services (Azure AD SSO tokens)
- Category: Spoofing
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, token theft, or compromised device) and impersonates employees/managers to submit or approve timesheets, view other users’ data, or change configuration.
- Mitigation Strategy: Enforce strong Azure AD configuration: require MFA/conditional access, short token lifetimes, refresh token rotation, device compliance checks, detect anomalous sign-ins, revoke tokens on suspicious activity. Implement session management and token binding where possible. Monitor and alert on unusual approval activity.
- Controls Applied: Azure AD SSO, MFA, Conditional Access, Session management, Anomaly detection
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-004 - Application Services (Approval API)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: An attacker modifies API requests (parameter tampering) to set approval fields (e.g., approved=true) or change timesheet status without proper authorization checks, enabling unauthorized approvals or status changes.
- Mitigation Strategy: Implement server-side authorization checks (verify caller identity & role), require explicit manager identity verification for approval endpoints, enforce immutability of submitted timesheets unless a documented reject/amend flow exists, and validate every state transition with business rules.
- Controls Applied: RBAC, Authorization middleware, State transition validation, Audit logs
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-005 - Data Storage / Operational Services (Audit logs)
- Category: Repudiation
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Insufficient or modifiable audit logging allows users (or attackers) to deny actions or to remove traces of malicious changes (e.g., approvals, delegation changes) so incidents cannot be proven.
- Mitigation Strategy: Store audit logs in tamper-evident/immutable storage (WORM), sign logs, use append-only streams, forward logs to an external SIEM, protect log ingestion credentials, and implement strict access control and monitoring for log access.
- Controls Applied: Immutable blob storage (WORM), SIEM, Append-only logs, Separation of duties
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-007 - Data Storage (Relational DB / Blobs)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Data stored without proper encryption or network isolation is exposed via cloud console compromise, misconfigured storage ACLs, or stolen backups leading to leakage of user profiles, timesheets, and balances.
- Mitigation Strategy: Encrypt data at rest (managed keys or HSM), enable network isolation (private endpoints, VNet), enforce least-privilege IAM for DB and storage, rotate keys, and regularly scan for publicly exposed buckets/containers.
- Controls Applied: Encryption at rest, Private endpoints, Storage ACLs, Key rotation
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-008 - Application Services (APIs enforcing team hierarchy)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Broken access control or misapplied team hierarchy rules cause the API to return timesheet or holiday data to unauthorized users (e.g., employees viewing other teams’ data).
- Mitigation Strategy: Implement robust RBAC/ABAC policies, verify team membership server-side on every request, use least privilege, automated access-control unit tests, and perform periodic access reviews and penetration testing focused on horizontal data access.
- Controls Applied: RBAC/ABAC, Authorization tests, Least privilege
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-009 - Application Services / Operational Services (Administrator accounts)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Administrator (or admin API credential) compromise permits system-wide configuration changes (workweek rules, audit log deletion or view), user management abuse, or backdoor creation.
- Mitigation Strategy: Protect admin accounts with stronger controls: enforced MFA, privileged identity management (just-in-time elevation), segmented admin interfaces, audit of admin actions, and strict approval/workflow for admin changes.
- Controls Applied: Privileged Access Management, MFA, Just-In-Time access, Admin audit trails
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-010 - Edge Layer (CDN/WAF/DDoS)
- Category: Denial of Service
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Volumetric or application-layer DDoS against the CDN/WAF or API gateway causes service disruption preventing users from submitting/approving timesheets or accessing holiday requests.
- Mitigation Strategy: Enable cloud provider DDoS protection, autoscaling, WAF rate rules, geo-blocking for suspicious traffic, traffic scrubbing, and runbook for failover and communication. Test resilience regularly.
- Controls Applied: Cloud DDoS protection, WAF, Autoscaling, Traffic scrubbing
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-012 - Integration & External Services (Email)
- Category: Spoofing
- Likelihood: High | Impact: Medium
- Initial Risk Level: High
- Description: Attackers send spoofed emails resembling system notifications (approval requests or delegation changes) to trick users into clicking malicious links or divulging credentials.
- Mitigation Strategy: Publish and enforce SPF/DKIM/DMARC for sending domains, include secure link patterns, educate users on phishing, include in-app verification of actions, and consider signed emails or HMACed notification tokens.
- Controls Applied: SPF/DKIM/DMARC, Email signing, User training
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-013 - Frontend Layer (SPA) / Application Services (API responses)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Stored or reflected XSS in the SPA exposes authentication cookies, tokens, or visible sensitive data, allowing account takeover or data leakage.
- Mitigation Strategy: Implement output encoding, input validation, Content Security Policy (CSP), use httpOnly and secure cookie flags, sanitize HTML and third-party content, and perform SAST/DAST focused on XSS.
- Controls Applied: Output encoding, CSP, Sanitization, Secure cookie flags
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-019 - Manager Delegation / Data Storage
- Category: Spoofing
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: An attacker modifies delegation records (direct DB write or API tampering) to make themselves or a malicious user a delegate, allowing approvals and access to team timesheets.
- Mitigation Strategy: Restrict delegation changes to authenticated manager flows with two-factor confirmation for delegation grants, send email/ in-app notifications for delegation creation, enforce server-side validation of who can create delegations, and audit delegation changes.
- Controls Applied: Server-side authorization, Notifications, Audit logging, Two-factor confirmation for sensitive changes
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-021 - Application Services (API/DB)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: SQL injection or other injection vulnerabilities in APIs allow attackers to modify or view database entries including timesheets, user data, or audit records.
- Mitigation Strategy: Use parameterized queries/ORM, input validation and whitelisting, enforce least-privilege DB accounts, use WAF signatures as defense-in-depth, and run automated SAST/DAST and regular penetration testing.
- Controls Applied: Parameterized queries, ORM, WAF, SAST/DAST
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-022 - Data Storage (Backups / Cloud storage)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Misconfigured backups or snapshots (publicly accessible storage or weak ACLs) expose complete datasets including PII and payroll-relevant timesheet records.
- Mitigation Strategy: Restrict backup storage to private networks, enforce encryption, audit and monitor storage ACL changes, automate scanning for public buckets, and secure backup management credentials.
- Controls Applied: Private backup endpoints, Backup encryption, ACL monitoring
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-024 - Application Services (Authorization / RBAC)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Broken access control (e.g., insecure direct object references or missing checks) allows regular employees to view or approve timesheets for other teams, leading to fraud and privacy breach.
- Mitigation Strategy: Enforce per-request authorization checks, avoid client-provided identifiers for access decisions, implement ABAC where appropriate, write comprehensive authorization tests, and perform regular access control audits and pentests.
- Controls Applied: Per-request authorization, ABAC/RBAC, Access testing
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-026 - Edge Layer / Frontend (CDN delivered JS)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Compromise of CDN or supply chain leads to malicious JavaScript being served to clients, enabling credential theft, XSS, or DOM-based manipulation of timesheet data.
- Mitigation Strategy: Use Subresource Integrity (SRI), pin dependencies, host critical JS from trusted origins or inline critical code, monitor CDN integrity, enable automated dependency scanning, and employ CSP to limit impacts.
- Controls Applied: SRI, Dependency pinning, CSP, Vendor risk management
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
THR-027 - Edge Layer / Application Services (TLS termination)
- Category: Information Disclosure
- Likelihood: Low | Impact: High
- Initial Risk Level: High
- Description: Weak or misconfigured TLS (old ciphers, expired certs, no HSTS) allows man-in-the-middle attacks to intercept tokens or timesheet data in transit.
- Mitigation Strategy: Enforce TLS 1.2+ (prefer 1.3), disable weak ciphers, implement HSTS, use managed certificate services, monitor certificate expiry, and encrypt internal service-to-service traffic.
- Controls Applied: TLS 1.2+/1.3, HSTS, Managed certs
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-029 - Operational Services / Data Storage (Insider threat)
- Category: Denial of Service
- Likelihood: Low | Impact: High
- Initial Risk Level: High
- Description: Insider (malicious or compromised admin) deletes or rolls back audit logs, backups, or critical configuration leading to loss of integrity or availability of forensic evidence.
- Mitigation Strategy: Use immutable backups/WORM for audit logs, enforce separation of duties, restrict admin operations via privileged access management, alert on mass deletes/backup changes, and maintain off-site/offline copies.
- Controls Applied: WORM backups, Separation of duties, PAM (Privileged Access Management), Offsite backups
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-030 - Integration & Data Storage (Cloud IAM & managed identities)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Initial Risk Level: High
- Description: Misconfigured cloud IAM roles or overly-permissive managed identities allow services or users to gain higher privileges (e.g., DB admin), leading to data exfiltration or system takeover.
- Mitigation Strategy: Apply least-privilege IAM policies, use managed identities with limited scopes, periodically review roles and permissions, implement role-approval workflows, and monitor IAM changes with alerts.
- Controls Applied: Least-privilege IAM, Managed identities, Periodic role review, IAM change monitoring
- Control Effectiveness: Medium
- Residual Risk Level: Medium
- Status: ⚠️ Requires Review
Medium Risk Threats
THR-002 - Frontend Layer / Application Services (JWT/session handling)
- Category: Spoofing
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Session fixation or manipulation of client-side tokens (JWT tampering) leading to unauthorized access if signatures aren’t verified or token claims aren’t validated server-side.
- Mitigation Strategy: Use signed JWTs with server-side validation, short token TTL, secure storage (httpOnly, secure cookies), token revocation lists, refresh token rotation, and reject tokens with tampered claims. Validate token audience/issuer/nonce.
- Controls Applied: JWT signature verification, Secure cookie flags, Token revocation, Server-side validation
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-006 - Integration & External Services (Email notifications)
- Category: Information Disclosure
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Sensitive timesheet or personnel data is leaked via email notifications (e.g., detailed timesheet contents, manager comments), exposing PII or other sensitive information to unintended recipients or through insecure email transport.
- Mitigation Strategy: Minimize content in emails (use placeholders and secure links to the app), avoid PII in email bodies, enforce TLS for SMTP/API, redact sensitive fields, and support expiring secure links for details. Document email templates and review for leakage.
- Controls Applied: Secure email (TLS), Email template review, Redaction, Secure links
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-011 - Application Services / Message Queue
- Category: Denial of Service
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: API abuse or lack of rate limiting causes queue/backlog storm (notification/reporting jobs), exhausting resources and delaying critical approval or reporting operations.
- Mitigation Strategy: Enforce API rate limiting and quotas per user/tenant, backpressure and circuit breaker patterns, prioritize critical jobs, and implement monitoring/alerts for queue depths.
- Controls Applied: Rate limiting, API gateway quotas, Circuit breakers, Job prioritization
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-014 - Data Storage (Blob attachments)
- Category: Tampering
- Likelihood: Low | Impact: Medium
- Initial Risk Level: Medium
- Description: An attacker replaces or tampers with uploaded attachments (e.g., receipts, evidence) stored in blob storage, undermining audit integrity or providing falsified evidence.
- Mitigation Strategy: Enable immutable (WORM) storage or versioning for attachments, use signed URLs with narrow time windows, store checksums/hashes in DB, and log upload/replace actions with identity.
- Controls Applied: WORM blob storage, Blob versioning, Signed URLs, Checksum validation
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-015 - Application Services / Operational Services (Audit & Approval)
- Category: Repudiation
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Manager or delegate claims they did not approve/reject a timesheet because audit trails lack signed identity/timestamp or the system allows anonymous approvals via email links.
- Mitigation Strategy: Record full identity and context for approvals (user id, auth token claims, IP, device), avoid email-only approval without in-app confirmation, and timestamp + sign approval events. Retain logs in immutable storage and backup.
- Controls Applied: Signed audit records, In-app approval flows, Immutable retention
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-016 - Manager Delegation (Application Services)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: A delegate uses delegated permissions beyond the defined scope or after the delegation expiry (e.g., approving for the wrong team or outside date range).
- Mitigation Strategy: Enforce delegation scope and start/end validation server-side for every approval attempt, notify original manager and delegate on delegation changes, log all delegated actions, and provide an audit and revoke capability.
- Controls Applied: Scope checks, Delegation expiry enforcement, Notifications, Audit
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-017 - Application Services (Business rules engine)
- Category: Tampering
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Misconfiguration or unauthorized modification of business rules (e.g., min/max hours, public holidays) leads to incorrect enforcement, allowing overworked/underworked entries or bypassing holiday application.
- Mitigation Strategy: Protect configuration change paths with RBAC, require approval and audit for business rule changes, validate rule changes in staging with automated tests, and provide immutable history of rule versions.
- Controls Applied: Change control, RBAC, Testing/CI, Config versioning
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ⚠️ Requires Review
THR-018 - Operational Services (Monitoring & Logs)
- Category: Information Disclosure
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Debug or verbose logs in production include tokens, PII, or timesheet content which are accessible to engineering or third-party monitoring tools, leading to data exposure or leakage.
- Mitigation Strategy: Implement logging policy to redact PII and secrets, use structured logging with redaction, restrict access to logs by role, and configure monitoring/third-party integrations to avoid ingesting sensitive data.
- Controls Applied: Logging redaction, Access control for logs, Monitoring policies
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-023 - Application Services / Notifications (Message Queue)
- Category: Denial of Service
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Maliciously or accidentally triggering large-scale notifications (e.g., mass delegation or submission events) overwhelms the notification service or queue, delaying or dropping critical messages.
- Mitigation Strategy: Implement per-user/event rate limiting for notifications, batching, queuing limits, backpressure handling, and monitoring with alerts for queue saturation. Use retry/backoff strategies.
- Controls Applied: Notification rate limiting, Queue throttling, Monitoring
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-025 - Frontend Layer / Application Services (CSRF vector)
- Category: Tampering
- Likelihood: Medium | Impact: Medium
- Initial Risk Level: Medium
- Description: Cross-Site Request Forgery (CSRF) allows a remote site to trigger manager actions (e.g., approve a timesheet) if the app relies solely on cookies without CSRF protections.
- Mitigation Strategy: Use anti-CSRF tokens or SameSite=strict cookies, require double-submit cookies or origin checks for state-changing requests, and avoid unsafe methods with cookie-based auth for sensitive operations.
- Controls Applied: CSRF tokens, SameSite cookies, Origin checks
- Control Effectiveness: High
- Residual Risk Level: Low
- Status: ✅ Accepted
THR-028 - Integration & External Services (Transactional Email provider)
- Category: Repudiation
- Likelihood: Low | Impact: Medium
- Initial Risk Level: Medium
- Description: Transactional email provider fails to provide reliable delivery receipts or manipulates logs, creating gaps that make it difficult to prove notifications were sent or received.
- Mitigation Strategy: Keep local audit logs of notification events, store delivery statuses from the provider, choose reputable providers with immutable logs/features, and have fallback notification channels (in-app/SM S).
- Controls Applied: Local notification audit, Provider logging, Fallback channels
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ✅ Accepted
Low Risk Threats
THR-020 - Integration & External Services (Public holiday feeds)
- Category: Information Disclosure
- Likelihood: Low | Impact: Low
- Initial Risk Level: Low
- Description: A malicious or compromised public holiday feed provides malformed or malicious data, or leaks organization-specific mappings causing incorrect holiday application or confusion in timesheets.
- Mitigation Strategy: Validate and sanitize external feed data, sandbox import process, apply whitelist rules, and allow administrators to approve feed changes. Monitor for anomalies and fallback to cached known-good data.
- Controls Applied: Feed validation, Sandboxing, Admin approval
- Control Effectiveness: Medium
- Residual Risk Level: Low
- Status: ✅ Accepted
Risk Reduction Summary:
- Critical Risk Reduction: 1 threats reduced from Critical to lower levels
- High Risk Reduction: 17 threats reduced from High to lower levels
- Residual Risk Distribution: 1 threats remain at Critical/High level
5.3. Risk Summary
The timesheet application has a moderate-to-high overall risk posture with the most critical threats arising from tampering of timesheet data (THR-003), broken access control and elevation of privilege pathways (THR-004, THR-024, THR-030), injection vulnerabilities (THR-021), and compromise of authentication tokens or high-privilege accounts (THR-001, THR-009). Key attack vectors include compromised or stolen tokens (Azure AD), API endpoints (parameter tampering, SQL injection), client-side attacks (XSS, supply chain via CDN), misconfigured cloud storage/backups, and third-party integrations (email, holiday feeds). Immediate priority controls: enforce server-side validation and strict authorization (RBAC/ABAC) for all APIs, harden Azure AD (MFA, conditional access), implement immutable audit logging and robust monitoring/SIEM, enable encryption and private networking for storage/backups, apply WAF and rate-limiting at the edge, and remediate secure coding issues (parameterized queries, XSS defenses). Secondary priorities include delegation scope enforcement, secure notification design (no sensitive data in emails), supply chain protections (SRI/dependency pinning), and regular permission reviews. Many high risks can be materially reduced by these controls (server-side checks, RBAC, strong Azure AD configuration, WORM logs, and encryption); residual medium risks remain where human factors or complex integrations exist and should be addressed via process controls, monitoring, and periodic audits.
6. Multi-Standard Security Requirements Mapping
This section maps each functional requirement to specific security controls from multiple industry standards: OWASP Application Security Verification Standard (ASVS), NIST SP 800-53 Rev 5, and ISO 27001:2022. This multi-standard approach provides comprehensive coverage across application-level, enterprise-level, and organizational-level security domains:
- OWASP ASVS: Application-level security controls (code, APIs, authentication, session management)
- NIST SP 800-53: Enterprise security controls (governance, risk management, incident response)
- ISO 27001: Information security management controls (policies, procedures, organizational controls)
Requirements are prioritized based on risk assessment and compliance needs, with controls selected from the most appropriate standard(s) for each requirement type.
6.1. Recommended ASVS Compliance Level
Recommended Level: L2
Level 2: Standard
Recommended for most production applications. Provides comprehensive security coverage suitable for applications handling sensitive data or operating in regulated environments. Includes controls for authentication, authorization, data protection, and secure communications.
The recommendation considers factors such as:
- Data sensitivity and classification levels
- Regulatory and compliance requirements (GDPR, HIPAA, PCI-DSS, etc.)
- Threat landscape and risk assessment from threat modeling
- Business criticality and potential impact of security incidents
All security controls referenced in this document align with this recommended compliance level.
6.2. Requirements Mapping
This section maps each high-level requirement to specific security controls from multiple standards (OWASP ASVS, NIST SP 800-53, ISO 27001) with detailed descriptions, relevance explanations, and integration guidance. Controls are grouped by standard for clarity.
6.2.1. REQ-001: Role-based access control with Employee, Manager, Delegate, and Administrator roles
OWASP ASVS Controls
ASVS 2.1
Requirement: Verify that role-based access control is implemented and enforced server-side.
Relevance: Directly mandates server-side enforcement of RBAC which is essential to prevent client-side bypass of role restrictions for Employees, Managers, Delegates and Administrators.
Integration Tips: Enforce RBAC checks in server-side business logic and APIs, centralize authorization logic, and avoid relying on client-side UI restrictions. Use policy-driven access checks and test for privilege escalation.
Verification Method: Code review of authorization checks, automated tests simulating role-based access attempts, and penetration testing for role escalation vulnerabilities.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AC-02
Requirement: The information system manages information system accounts, including establishing, activating, modifying, disabling, and removing accounts. The organization assigns account managers and implements role-based access controls.
Relevance: This control describes the need to manage user accounts and implement role-based access controls which directly maps to defining Employee, Manager, Delegate, and Administrator roles and their lifecycle.
Integration Tips: Implement an account management module to create, modify, disable and remove accounts, with role assignment workflows for Employee/Manager/Delegate/Admin. Tie account lifecycle events to HR/ID provider events to auto-deactivate accounts when necessary.
Verification Method: Review account management procedures, inspect role assignment workflows, and test create/modify/disable/delete operations for each role; verify role enforcement in code and access control lists.
Priority: Critical
ISO 27001:2022 Controls
A.9.1.2
Requirement: Users shall only be provided with access to the network and network services that they have been specifically authorized to use.
Relevance: Ensures that each role is granted only the specific access required, aligning with role separation between Employees, Managers, Delegates and Administrators.
Integration Tips: Define an access control policy that enumerates permitted actions for each role and ensure technical enforcement in application and API layers. Maintain documentation linking roles to authorized services and verify provisioning matches policy.
Verification Method: Audit role-to-permission mappings, perform access control tests (positive and negative) for each role, and verify that unauthorized actions are blocked.
Priority: High
6.2.2. REQ-002: Azure SSO integration for authentication and single sign-on
OWASP ASVS Controls
ASVS 2.3
Requirement: Verify correct implementation of federated authentication (SAML, OAuth2/OIDC) and that the application properly validates assertions and tokens from identity providers.
Relevance: Azure SSO relies on federated protocols (OIDC/OAuth2/SAML); this control ensures tokens/assertions from Azure AD are validated to prevent impersonation and token forgery.
Integration Tips: Use a tested OIDC/SAML library, validate issuer, audience, token signatures and claims, enforce token expiration and revocation, and implement proper redirect URIs. Integrate Azure AD metadata and rotate keys per provider guidance.
Verification Method: Review integration code/configuration, verify token validation logic, test with malformed tokens and revoked credentials, and perform federated auth flow penetration testing.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
IA-08
Requirement: The information system supports organizational users leveraging federated identities and authenticates via approved identity providers.
Relevance: Specifies support for federated authentication which maps to using Azure AD as the identity provider for SSO.
Integration Tips: Document and restrict approved identity providers to Azure AD, ensure trust anchors and metadata are configured, and include fallback/incident procedures for IdP outages.
Verification Method: Validate configuration against Azure AD metadata, test sign-on flows for multiple scenarios (fresh login, SSO, logout), and review IdP trust settings.
Priority: High
ISO 27001:2022 Controls
A.9.4.2
Requirement: Where required by the business, users shall be provided with a secure log-on procedure which may include SSO solutions.
Relevance: Supports SSO as a recognized secure logon mechanism to be used when integrating Azure SSO for authentication.
Integration Tips: Ensure SSO configuration follows secure logon procedures, include multi-factor authentication where required, and document SSO use in access control policy.
Verification Method: Review secure logon procedure documentation, test SSO flows for MFA and session handling, and confirm configuration meets organizational security requirements.
Priority: High
6.2.3. REQ-003: User management and team hierarchy mapping (assign managers, teams, delegates)
OWASP ASVS Controls
ASVS 2.5
Requirement: Verify that user account management functions (create, update, disable, delete) are implemented with role-based constraints and administrative controls.
Relevance: Mandates secure account management features which are necessary to implement hierarchical relationships and delegation safely.
Integration Tips: Provide admin UI/API that enforces role-based constraints, log all changes to user/team assignments, and require approvals for sensitive changes like manager/delegate reassignment.
Verification Method: Code and configuration review of account management APIs, functional tests for reassigning managers/delegates, and logs verifying change history.
Level: L2 | Priority: High
NIST SP 800-53 Controls
AC-02
Requirement: The information system manages information system accounts, including establishing, activating, modifying, disabling, and removing accounts. The organization assigns account managers and implements role-based access controls.
Relevance: Account Management covers provisioning and role assignments required for mapping team hierarchies and assigning manager/delegate relationships.
Integration Tips: Implement structured account provisioning with attributes for team, manager, and delegate fields; integrate with HR/IdP to synchronize hierarchies and automate lifecycle actions.
Verification Method: Audit provisioning logs, test automated synchronization against HR records, and review the process for creating/updating hierarchical relationships.
Priority: Critical
ISO 27001:2022 Controls
A.9.2.2
Requirement: The allocation and use of privileges shall be restricted and controlled. A formal user access provisioning process shall be implemented to assign roles and privileges.
Relevance: Formal provisioning is needed to ensure teams and managers are assigned consistent privileges and that delegation is controlled.
Integration Tips: Establish documented provisioning procedures, include approvals for manager/delegate assignments, and implement access reviews to validate team mappings periodically.
Verification Method: Review provisioning workflow documentation, sample user profiles for correct team/manager attributes, and examine periodic access review records.
Priority: High
6.2.4. REQ-004: Daily and weekly timesheet entry supporting multiple projects/tasks
OWASP ASVS Controls
ASVS 5.1
Requirement: Verify business logic functions, including multi-step workflows and data correctness for application-specific processes like timesheet entries.
Relevance: Ensures the application enforces correct business logic for multi-project/task timesheets and captures intended behaviour for daily/weekly entries.
Integration Tips: Model workflows for daily/weekly entry, include project/task validation and cross-field checks, and implement unit/integration tests covering typical and edge cases.
Verification Method: Functional testing of timesheet workflows, review test coverage for multiple projects/tasks, and validate business rule enforcement during entry.
Level: L2 | Priority: High
NIST SP 800-53 Controls
SI-12
Requirement: The information system validates the accuracy and integrity of data inputs and detects input errors or malicious inputs.
Relevance: Timesheet entries are user inputs that must be validated for integrity, format and allowed values (projects/tasks) to prevent data corruption or abuse.
Integration Tips: Implement server-side validation for project/task identifiers, check hours totals against configured rules, and sanitize inputs to prevent injection or malformed data.
Verification Method: Run automated input validation tests, review validation code, and attempt injection and malformed input tests against timesheet entry endpoints.
Priority: Critical
AU-12
Requirement: The system associates user identities with actions, ensuring timesheet entries can be attributed and audited.
Relevance: Attribution ensures entries are tied to the submitting user, supporting accountability for daily/weekly timesheet data.
Integration Tips: Record user identifiers and session details with each timesheet entry, and ensure audit trails are immutable and retained per policy.
Verification Method: Inspect logs and entries to confirm user attribution fields are recorded and cannot be altered by normal users.
Priority: High
6.2.5. REQ-005: Save draft timesheets with validation preventing submission until required fields completed
OWASP ASVS Controls
ASVS 5.3
Requirement: Verify that input validation and business rule enforcement prevents invalid state transitions (e.g., prevent submission until required fields are completed).
Relevance: Directly addresses preventing invalid state transitions between draft and submitted timesheet states until validation passes.
Integration Tips: Implement server-side state machine enforcing ‘draft’ vs ‘submitted’ states, validate required fields on submission API calls, and disallow client-only validations.
Verification Method: Attempt to submit incomplete drafts via API, review server-side validation code and test state transitions with automated tests.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
SI-10
Requirement: The application checks and validates input data for completeness and correctness before processing or submission.
Relevance: Requires completeness checks on inputs which align with preventing submissions of incomplete timesheets.
Integration Tips: Enforce required-field checks on submission endpoints, and log validation failures for monitoring and user feedback.
Verification Method: Review validation rules, attempt invalid submissions, and confirm server rejects submissions until fields are complete.
Priority: High
ISO 27001:2022 Controls
A.14.2.5
Requirement: Security requirements for applications including validation and error handling shall be addressed during development.
Relevance: Mandates considering validation/error handling in development, ensuring draft-save vs submit behaviors are securely implemented.
Integration Tips: Include validation and state-change rules in security requirements, perform threat modeling for state transitions, and include validation tests in CI/CD.
Verification Method: Review development artefacts and tests for validation logic and confirm error handling prevents submission of incomplete drafts.
Priority: Medium
6.2.6. REQ-006: Timesheet submission workflow with submission timestamp and read-only state after submission
OWASP ASVS Controls
ASVS 5.2
Requirement: Verify that state transitions are enforced server-side and that submitted records become immutable/read-only if required by business rules.
Relevance: Directly mandates server-side enforcement of read-only state post-submission to prevent unauthorized edits.
Integration Tips: Implement immutability by enforcing access control checks and storing a submitted flag preventing modification; use DB constraints or write-once storage for submitted records.
Verification Method: Attempt to alter a submitted timesheet via UI and API; review server-side checks and database constraints ensuring immutability.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AU-2
Requirement: The information system determines which events (such as submission) are to be audited and records sufficient information including timestamps.
Relevance: Specifies that submissions must be audited with timestamps which supports the requirement for submission timestamps.
Integration Tips: Record submission events with user ID, timestamp, and submission metadata in an append-only audit log, and ensure timestamp source is trusted (e.g., server time).
Verification Method: Review audit logs for submission events and timestamps; verify logs are tamper-evident and properly correlated to submission records.
Priority: Critical
ISO 27001:2022 Controls
A.12.4.1
Requirement: Event logs recording user activities and timestamps shall be maintained to support later review and investigations.
Relevance: Supports retention of submission timestamps and event records to enable audits and investigations for submitted timesheets.
Integration Tips: Ensure submission events are logged centrally and retained per retention policy; log who changed status and when.
Verification Method: Review logging configuration, confirm logs include submission events/timestamps, and test retention/archival processes.
Priority: High
6.2.7. REQ-007: Approval/rejection workflow for managers and delegates, including comments and logging
OWASP ASVS Controls
ASVS 5.2
Requirement: Verify that workflow actions (approve/reject) are properly authorized, logged, and include support for comments and evidence.
Relevance: Specifies that approval actions must be authorized and logged and support comments — directly mapping to the requirement.
Integration Tips: Enforce authorization checks that confirm approver is manager/delegate for the employee, persist comments and evidence, and ensure UI/API present required metadata.
Verification Method: Test approval/rejection flows, attempt unauthorized approvals, and review audit entries for comments and evidence retention.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AU-6
Requirement: The organization reviews and analyzes audit records for indications of inappropriate activity; approvals/rejections should be auditable.
Relevance: Mandates auditability of approval/rejection actions which is required for manager/delegate workflows including comments.
Integration Tips: Log approval/rejection events with user id, role, timestamp and comment; integrate with audit review processes to detect anomalies in approvals.
Verification Method: Inspect logs for approval/rejection entries, verify comments are stored and reviewers can reconstruct the decision chain.
Priority: Critical
ISO 27001:2022 Controls
A.12.1.3
Requirement: Ensure operations are controlled and that changes and approvals are managed and recorded.
Relevance: Reinforces operational control over changes and approvals which supports structured approval workflows with logging.
Integration Tips: Document approval procedures and ensure system enforces required approvals and captures comments; include these in operational runbooks.
Verification Method: Review procedural documents, sample approvals to confirm process adherence, and verify logs for completeness.
Priority: High
6.2.8. REQ-008: Manager delegation with start/end dates, scope of permissions, revocation, and notifications
OWASP ASVS Controls
ASVS 2.5
Requirement: Ensure that delegation and temporary role assignments are time-bound and auditable, and support revocation.
Relevance: Directly requires time-bound delegation, auditable assignments and revocation mechanisms matching the requirement’s needs.
Integration Tips: Provide UI/APIs to create time-bound delegation entries, implement automatic expiry and immediate revocation endpoints, and generate notifications on changes.
Verification Method: Create delegated roles, verify automatic expiry, execute revocation and confirm notifications and audit entries are generated.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AC-05
Requirement: The organization separates duties of individuals as necessary, and implements delegation controls to define scope and limits of permissions.
Relevance: Addresses the need to control delegation scope and ensure duties are appropriately segregated and limited in time and scope.
Integration Tips: Implement delegation records with start/end timestamps and scoped permissions; ensure separation-of-duty checks prevent conflict-of-interest delegations.
Verification Method: Review delegation records, test enforcement of scope and time boundaries, and perform conflict-of-interest checks.
Priority: High
ISO 27001:2022 Controls
A.6.1.2
Requirement: Conflicts of interest are reduced by segregating duties and defining responsibilities, including delegation rules.
Relevance: Supports defining delegation rules and responsibilities to reduce conflicts when delegating managerial tasks.
Integration Tips: Document delegation policies with approval steps, maintain a registry of active delegations, and send notifications for assignment/revocation.
Verification Method: Inspect delegation registry and policy documents, and confirm notifications are issued on changes.
Priority: High
6.2.9. REQ-009: Holiday and leave request management with leave balance tracking and manager approval
OWASP ASVS Controls
ASVS 5.1
Requirement: Verify business processes like leave requests and balance calculations are implemented correctly and prevent abuse.
Relevance: Ensures leave balances and approval logic are implemented correctly to prevent fraudulent requests or incorrect balances.
Integration Tips: Implement server-side calculation of balances, include checks against overlapping leaves, and require manager approval with audit trail.
Verification Method: Functional tests of leave balance computations, attempts to bypass approvals, and verify audit trails for approvals.
Level: L2 | Priority: High
NIST SP 800-53 Controls
AC-02
Requirement: The information system manages accounts including attributes; systems supporting leave should manage state and approvals.
Relevance: Account attributes and state management apply to leave status and approvals linked to user accounts.
Integration Tips: Store leave balances as account attributes and enforce manager approval before state changes; log changes for audit.
Verification Method: Examine account attributes for leave balance fields, review approval logs, and confirm state transitions require manager action.
Priority: High
ISO 27001:2022 Controls
A.7.2.2
Requirement: Employees should be made aware of information security responsibilities; HR processes should include leave and absence management controls.
Relevance: Links HR processes (leave management) with security responsibilities and supports integrating leave tracking securely in systems.
Integration Tips: Integrate leave management with HR systems, enforce approval workflows with manager authorization, and protect leave balance data as personal information.
Verification Method: Review HR integration points, test leave request workflows and manager approvals, and verify PII protections for leave balances.
Priority: Medium
6.2.10. REQ-010: Public holiday preload and auto-application to timesheets
OWASP ASVS Controls
ASVS 5.1
Requirement: Verify system-provided data and configurable presets (e.g., public holidays) are applied consistently and cannot be tampered with by unauthorized users.
Relevance: Ensures preloaded public holiday data cannot be altered by unprivileged users and is applied consistently to timesheets.
Integration Tips: Restrict modification of holiday data to administrators, sign or checksum holiday datasets to detect tampering, and log changes with approvals.
Verification Method: Attempt unauthorized modification of holiday data, review access controls, and verify integrity checks for datasets.
Level: L2 | Priority: High
NIST SP 800-53 Controls
CM-2
Requirement: Establish and maintain baseline configurations for information systems including configurable data sets.
Relevance: Public holiday datasets are configurable data; baselining ensures controlled updates and integrity of this data.
Integration Tips: Treat public holiday data as configuration items with versioning, approvals for changes, and rollback procedures for erroneous updates.
Verification Method: Inspect configuration baselines and version history for holiday data and test rollback and update processes.
Priority: High
ISO 27001:2022 Controls
A.12.1.1
Requirement: Operating procedures should be documented; application configuration (like public holidays) must be managed and documented.
Relevance: Requires documenting procedures for preloading public holidays and how they are applied to timesheets, useful for configuration control and auditing.
Integration Tips: Maintain documented configuration procedures for public holiday datasets, include change approval for holiday lists, and ensure changes are logged and tested.
Verification Method: Review documentation, inspect configuration change logs, and verify that holiday preload processes are followed and auditable.
Priority: Medium
6.2.11. REQ-011: Business rules enforcement: configurable workweek, min/max hours, working patterns
OWASP ASVS Controls
ASVS 5.3
Requirement: Verify business rule enforcement (configurable policies like workweek, min/max hours) is applied server-side and cannot be bypassed.
Relevance: Directly maps to ensuring business rules (workweek, hours) are enforced server-side and are configurable in a controlled manner.
Integration Tips: Model business rules as policy objects enforced in backend services, provide administrative UI for configuration with approvals, and validate rules on every submission.
Verification Method: Test rule configuration changes, attempt to submit timesheets violating rules, and review server-side enforcement in logs and code.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AC-06
Requirement: The organization employs the concept of least privilege, ensuring users are granted only the access necessary to perform their duties.
Relevance: Applies to who can configure business rules; restrict configuration changes to privileged admin roles following least privilege.
Integration Tips: Restrict business rule configuration to administrators with documented approvals and enforce separation of duties between config and approval roles.
Verification Method: Review role permissions for configuration actions and validate that non-admin users cannot alter business rules.
Priority: High
ISO 27001:2022 Controls
A.14.2.5
Requirement: Security requirements for applications including enforcement of business rules and validation shall be addressed during development.
Relevance: Mandates embedding business rule enforcement into secure development lifecycle to prevent bypasses.
Integration Tips: Include business rule enforcement tests in development pipelines and perform security reviews focusing on rule bypass risks.
Verification Method: Review secure development artefacts and test suites for business rule enforcement coverage.
Priority: Medium
6.2.12. REQ-012: Notifications via email for reminders, approval requests, approvals/rejections, and delegation changes
OWASP ASVS Controls
ASVS 14.1
Requirement: Ensure sensitive data transmitted via notifications (email) is protected and minimized (avoid including sensitive data in emails).
Relevance: Email notifications often contain PII or timesheet details; this control ensures sensitive content is minimized and protected.
Integration Tips: Avoid including sensitive details in emails — include links to the secure portal instead; if data is sent, use encryption and redaction as appropriate.
Verification Method: Audit email templates for sensitive content, test that emails contain minimal data and links require authentication to view details.
Level: L1 | Priority: High
NIST SP 800-53 Controls
SI-4
Requirement: Implement mechanisms to monitor system notifications and ensure integrity of messaging.
Relevance: Covers monitoring to ensure notification system integrity and detect anomalies in email delivery for reminders and approvals.
Integration Tips: Monitor notification delivery logs, set alerts for failures/unexpected volumes, and ensure traceability from event to sent notification.
Verification Method: Review notification logs, monitor alerting, and test end-to-end notification delivery and error handling.
Priority: Medium
ISO 27001:2022 Controls
A.10.1.1
Requirement: Use cryptographic controls to protect the confidentiality, integrity and availability of information, including notifications where appropriate.
Relevance: Applied to protect content of emails (when sensitive) and ensure SMTP channels or message stores use encryption and integrity controls.
Integration Tips: Use TLS for SMTP, sign emails or use secure notification services, and store notification records encrypted if they include PII.
Verification Method: Inspect email transport configuration for TLS, review encryption policy for stored notifications, and test interception resistance.
Priority: High
6.2.13. REQ-013: Reporting: weekly, monthly, and custom time reports for employees and managers
OWASP ASVS Controls
ASVS 10.1
Requirement: Verify that access control is applied to business functions such as report generation and data exports to ensure only authorized personnel can run them.
Relevance: Ensures reporting functions require appropriate authorization and respect role/team boundaries.
Integration Tips: Implement authorization checks inline with report generation functions; include masking/aggregation for non-authorized detail levels.
Verification Method: Review access control checks in reporting code and attempt to retrieve reports beyond assigned scope.
Level: L2 | Priority: High
NIST SP 800-53 Controls
AC-03
Requirement: The system enforces approved authorizations for logical access to information and system resources (apply to reports and exports).
Relevance: Reports and exports must be subject to access enforcement so employees/managers only see authorized data.
Integration Tips: Enforce RBAC/attribute-based checks at report generation time, filter results by viewer’s team scope and permissions, and restrict export endpoints.
Verification Method: Test report access for various roles, attempt to access others’ reports, and review enforcement logic in reporting services.
Priority: Critical
ISO 27001:2022 Controls
A.9.4.1
Requirement: Access to information and application system functions should be restricted in accordance with the access control policy (applies to reports and exports).
Relevance: Supports restricting access to reports per policy and aligns with data access requirements for managers and employees.
Integration Tips: Define report access policies and implement technical controls to restrict data exports and downloaden capabilities to authorized roles only.
Verification Method: Audit report access policies, review permission enforcement, and test enforcement across report types.
Priority: High
6.2.14. REQ-014: Audit logging of timesheet lifecycle events, approvals/rejections, delegation changes, and admin amendments
OWASP ASVS Controls
ASVS 10.5
Requirement: Verify sufficient logging is implemented to support reconstruction of events such as approvals, rejections and administrative changes.
Relevance: Specifies log content and sufficiency for reconstructing events related to timesheet lifecycle and admin changes.
Integration Tips: Ensure log entries include actor, timestamp, target resource, previous and new values, and reason/comment where applicable.
Verification Method: Reconstruct sample incidents from logs to ensure all necessary data is present and verify logs against event catalog.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AU-2
Requirement: The information system determines which events (such as timesheet lifecycle events) are to be audited and records them.
Relevance: Specifies selecting and recording audit events, directly mapping to timesheet lifecycle and admin actions logging.
Integration Tips: Define an audit event catalog for lifecycle events, ensure logs capture user identity, timestamp, action and context, and protect logs from tampering.
Verification Method: Review event catalog, examine logs for required events, and confirm tamper-evidence and retention settings.
Priority: Critical
ISO 27001:2022 Controls
A.12.4.1
Requirement: Event logs recording user activities and changes shall be maintained to support monitoring and investigation.
Relevance: Reinforces maintaining logs for activities like approvals, delegations and admin amendments to support investigations.
Integration Tips: Centralize logs, apply access controls to log access, and include procedures for log review and incident correlation.
Verification Method: Inspect centralized log store, test log integrity controls, and review monitoring procedures.
Priority: High
6.2.15. REQ-015: Administrator capabilities to configure system settings, working patterns, public holidays, and amend submitted timesheets
OWASP ASVS Controls
ASVS 2.5
Requirement: Verify administrative functions are protected and that only authorized administrators can change system configuration and amend data.
Relevance: Mandates that admin functions be tightly controlled — mapping to configuration and amendment capabilities in the requirement.
Integration Tips: Protect admin interfaces with strong authentication (MFA), log all admin actions, and require re-authentication or approvals for critical amendments.
Verification Method: Test admin access controls, verify MFA enforcement, and review audit records for admin amendments.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AC-5
Requirement: The organization separates duties of individuals as necessary and implements controls over privileged accounts (administrators).
Relevance: Requires separation and control of administrative privileges needed for configuration and amendment capabilities.
Integration Tips: Apply least privilege for admin roles, segregate duties across multiple admin roles (config vs amendments), and require approvals for high-impact changes.
Verification Method: Review admin role definitions, test segregation of duties, and inspect authorization requirements for admin actions.
Priority: Critical
ISO 27001:2022 Controls
A.9.2.3
Requirement: The allocation and use of privileged access rights shall be restricted and controlled.
Relevance: Specifies controlling privileged access which is required for admin capabilities to configure and amend submitted timesheets.
Integration Tips: Implement privileged access management (PAM) controls for admin accounts, maintain an approval trail for privilege grants, and periodically review privileged accounts.
Verification Method: Inspect PAM configuration and privileged account reviews, and test that privileged operations require appropriate authorization and logging.
Priority: High
6.2.16. REQ-016: Responsive and accessible UI compliant with WCAG guidelines
OWASP ASVS Controls
ASVS 14.2
Requirement: Verify that privacy and accessibility considerations are addressed in application design to prevent exclusion and leakage of private data.
Relevance: Addresses accessibility and privacy considerations in UI design; supports WCAG compliance to ensure accessible and privacy-preserving UI.
Integration Tips: Include accessibility checks in design and testing, avoid exposing sensitive data in UI components, and follow WCAG guidance for responsive layouts and alternatives.
Verification Method: Perform WCAG conformance testing, accessibility audits, and review UI designs for privacy exposures.
Level: L1 | Priority: Medium
NIST SP 800-53 Controls
PL-8
Requirement: Consider accessibility and usability as part of secure system architecture and design.
Relevance: Encourages including accessibility in the security architecture to ensure accessible systems meet security and compliance needs.
Integration Tips: Incorporate accessibility requirements into system architecture and threat models, and include assistive technology testing in QA.
Verification Method: Review architecture documents for accessibility considerations and test with assistive technologies.
Priority: Low
ISO 27001:2022 Controls
A.14.2.1
Requirement: Security and quality requirements for systems (including usability and accessibility) should be defined and implemented.
Relevance: Requires defining usability and accessibility as quality/security requirements in development, supporting WCAG compliance.
Integration Tips: Document WCAG targets in requirements, perform accessibility testing during development, and maintain remediation plans for issues found.
Verification Method: Review requirement documents, test plans, and evidence of WCAG testing and remediation activities.
Priority: Medium
6.2.17. REQ-017: Data access restrictions based on team hierarchy and least-privilege principles
OWASP ASVS Controls
ASVS 10.1
Requirement: Verify access control is applied to business functions and data based on roles and attributes, supporting least privilege and hierarchical restrictions.
Relevance: Specifies applying access control to business functions and data using roles and attributes, essential for team-hierarchy enforcement.
Integration Tips: Use centralized policy engine for attribute-based decisions (role + team), apply data filtering at query time, and protect APIs against elevation attempts.
Verification Method: Test attribute-based access control decisions in diverse scenarios and review implementation for gaps.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
AC-06
Requirement: The organization employs the concept of least privilege, ensuring users are granted only the access necessary to perform their duties.
Relevance: Directly requires least-privilege principles be applied to restrict data access per team hierarchy.
Integration Tips: Implement attribute-based access controls combining role and team attributes, periodically review privileges, and restrict admin capabilities.
Verification Method: Audit role assignments and permissions, perform privilege escalation tests, and validate enforcement of team-based filters.
Priority: Critical
ISO 27001:2022 Controls
A.9.4.1
Requirement: Access to information and application system functions should be restricted in accordance with the access control policy (supports team hierarchy restrictions).
Relevance: Mandates access restrictions aligned with policy, supporting hierarchy-based restrictions required by the application.
Integration Tips: Define access control policy reflecting team hierarchies and implement enforcement in application and data layers with logging.
Verification Method: Review policy and enforcement mechanisms, test cross-team access attempts, and confirm access logs reflect restrictions.
Priority: High
6.2.18. REQ-018: Data retention, encryption, and export capabilities to support compliance and integrations with payroll/HR
OWASP ASVS Controls
ASVS 14.1
Requirement: Verify that sensitive data is protected at rest and in transit using appropriate cryptography, and that export mechanisms are secure and auditable.
Relevance: Directly addresses encryption and secure export capabilities required for payroll/HR integrations.
Integration Tips: Use strong, up-to-date cryptographic algorithms for data at rest and TLS for transports, and log/export events with integrity checks and access controls.
Verification Method: Inspect encryption configurations, test secure export endpoints, and verify audit trails of export operations.
Level: L2 | Priority: Critical
NIST SP 800-53 Controls
MP-6
Requirement: Protect and sanitize media containing sensitive information prior to disposal; retention policies shall be enforced.
Relevance: Covers enforcing retention policies and sanitization for data exported or stored for payroll/HR integrations.
Integration Tips: Define retention schedules for timesheet and payroll data, implement scheduled purging and secure disposal, and document retention justifications for compliance.
Verification Method: Review retention policies, confirm automated purging processes, and verify proper sanitization/destruction procedures.
Priority: High
ISO 27001:2022 Controls
A.8.3.3
Requirement: Information shall be handled in accordance with its classification including retention and protection rules; support secure export.
Relevance: Requires classifying timesheet/payroll data and handling exports according to classification to meet compliance needs.
Integration Tips: Classify data, enforce encryption at rest and in transit for exports, and require contractual/technical controls for HR/payroll integration endpoints.
Verification Method: Review classification rules, inspect encryption controls, and test secure export workflows to payroll/HR.
Priority: Critical
6.3. Cross-Functional Security Controls
The following controls apply globally across all system components:
Audit Logging and Monitoring
Description: Centralized logging of critical events including account lifecycle, timesheet submissions, approvals, delegations, admin changes, exports and notifications to support investigations and compliance.
Applies to: All requirements that involve user actions, approvals, delegation, admin changes, submissions and exports
Implementation Guidance: Implement centralized, tamper-evident logging (SIEM or log store), standardize event schemas (actor, timestamp, action, context), protect log access, and establish log retention and review processes.
Encryption (Data at Rest and in Transit)
Description: Protect sensitive timesheet, personal and payroll/HR-related data using strong cryptography while stored and transmitted.
Applies to: Authentication/SSO tokens, notifications, stored timesheets, exports and integration endpoints
Implementation Guidance: Use TLS for transport, AES-256 or equivalent for data at rest, manage keys securely (KMS/PAM), and ensure integrations also use encrypted channels and signed payloads.
Access Control and RBAC Enforcement
Description: Centralized role-based and attribute-based access control enforcing least privilege across UI, APIs and data layers.
Applies to: User management, reporting, admin functions, delegation, and data access restrictions
Implementation Guidance: Use a centralized authorization service/policy engine, enforce checks server-side, maintain role/permission catalog, and require approval workflows for privileged changes.
Secure Development and Business Logic Validation
Description: Embed validation, business rule enforcement, and threat modeling into the SDLC to prevent logic bypasses and ensure correct state transitions.
Applies to: Timesheet entry, draft/save/submit workflows, business rules, holiday application and leave management
Implementation Guidance: Include server-side validation, automated tests for business rules, code reviews, and include business logic abuse cases in threat models and pentests.
6.4. Requirements Traceability Overview
This section demonstrates complete traceability from high-level requirements through threats to security controls and verification methods.
Coverage Summary: Traceability matrix contains 18 requirements. 17 requirements (94.4%) linked to threats. 17 requirements (94.4%) mapped to security controls (OWASP ASVS, NIST SP 800-53, ISO 27001). Coverage: Complete.
Sample Traceability Mappings
The following table shows traceability for high-priority requirements:
| Req ID | Requirement | Threats | Security Controls | Standards | Priority | Verification |
|---|---|---|---|---|---|---|
| REQ-001 | Role-based access control with Employee,… | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Code review of authorization checks, automated tests simulating role-based access attempts, and penetration testing for role escalation vulnerabilities. |
| REQ-002 | Integrate with Azure SSO for authenticat… | 4 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Validate configuration against Azure AD metadata, test sign-on flows for multiple scenarios (fresh login, SSO, logout), and review IdP trust settings. |
| REQ-003 | User management and team hierarchy mappi… | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Review provisioning workflow documentation, sample user profiles for correct team/manager attributes, and examine periodic access review records. |
| REQ-004 | Daily and weekly timesheet entry support… | 10 threats | 3 controls | NIST, OWASP | Critical | Functional testing of timesheet workflows, review test coverage for multiple projects/tasks, and validate business rule enforcement during entry. |
| REQ-005 | Save draft timesheets locally/server-sid… | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Attempt to submit incomplete drafts via API, review server-side validation code and test state transitions with automated tests. |
| REQ-006 | Timesheet submission workflow that recor… | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Attempt to alter a submitted timesheet via UI and API; review server-side checks and database constraints ensuring immutability. |
| REQ-008 | Manager delegation capabilities: assign … | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Inspect delegation registry and policy documents, and confirm notifications are issued on changes. |
| REQ-011 | Business rules engine to configure workw… | 9 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Test rule configuration changes, attempt to submit timesheets violating rules, and review server-side enforcement in logs and code. |
| REQ-013 | Reporting: generate weekly, monthly, and… | 6 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Test report access for various roles, attempt to access others’ reports, and review enforcement logic in reporting services. |
| REQ-017 | Enforce data access restrictions based o… | 10 threats | 3 controls | ISO27001, NIST, OWASP | Critical | Audit role assignments and permissions, perform privilege escalation tests, and validate enforcement of team-based filters. |
Showing 10 of 18 requirements. See Appendix D for complete traceability matrix.
Traceability Statistics
- Total Requirements Tracked: 18
- Requirements Linked to Threats: 17 (94.4%)
- Requirements Mapped to Controls: 17 (94.4%)
- Average Controls per Requirement: 2.8
- Control Distribution by Standard:
- NIST SP 800-53: 18 controls
- OWASP ASVS: 17 controls
- ISO 27001: 16 controls
- Verification Coverage: 100% (all requirements have verification methods)
7. AI/ML Security Requirements
This section addresses security requirements specific to artificial intelligence and machine learning components within the system. AI/ML systems introduce unique security challenges including prompt injection attacks, data poisoning, model theft, adversarial inputs, and bias vulnerabilities. This analysis identifies AI/ML components, assesses their security risks, and prescribes specialized controls to protect both the AI systems themselves and the data they process.
7.1. AI/ML Components Detected
This section identifies all AI/ML components within the system that require specialized security controls.
1. None Detected: After reviewing the requirements, there are no components that utilize AI/ML capabilities such as natural language processing, machine learning models, or other AI-powered features.
7.2. AI/ML Threat Model
| Component | Identified Threats |
|---|---|
| None Detected | - No AI/ML threats identified |
7.3. AI/ML Security Controls
There are no specific AI/ML security controls required as no AI/ML components were identified.
7.4. Integration with Existing Security Controls
Since there are no AI/ML components, the existing security controls such as role-based access control, data encryption, and audit logging remain sufficient for the application’s needs.
7.5. AI/ML Monitoring Requirements
| Monitoring Area | Description |
|---|---|
| None Detected | - No AI/ML monitoring required as no AI/ML components were identified. |
8. Compliance Requirements
This section identifies regulatory and legal compliance obligations applicable to the system based on data types, geographic scope, industry sector, and business operations. Compliance requirements drive specific security controls, data handling procedures, audit capabilities, and privacy protections. Non-compliance can result in significant legal penalties, reputational damage, and business disruption. This analysis maps applicable regulations to specific security requirements and operational procedures.
8.1. Applicable Regulations
In analyzing the requirements for the timesheet web application, we identified several regulatory frameworks that govern the handling of various types of data collected and processed by the application. The regulations were determined based on the types of data involved, the geographic scope of operations, and the nature of the business activities. Given that the application will handle personal data of employees, including potential health information and sensitive financial data, compliance requirements directly impact the security controls, data handling procedures, and operational processes of the application.
| Regulation | Applicability Reason |
|---|---|
| GDPR | Applies because the system processes personal data of EU residents. |
| CCPA | Applies due to the collection and processing of personal data of California residents. |
| HIPAA | Relevant if any health-related information is stored or processed (if applicable to employees). |
| PCI-DSS | Applies if the application processes any payment card data. |
| SOX | Relevant if the application handles financial data linked to corporate financial reporting. |
| GLBA | Applies if the application processes personal financial information. |
| COPPA | Relevant if the application collects data from children under 13. |
| Data Residency Laws | Applies based on the geographic location of the data storage and processing. |
8.2. Compliance Controls by Regulation
GDPR
- Ensure data minimization: Only collect data that is necessary for the purposes of the application.
- Implement user access controls: Enforce role-based access to sensitive personal data.
- Data encryption: Encrypt personal data in transit and at rest.
- Privacy by design: Incorporate privacy considerations into the application’s architecture.
CCPA
- Provide transparency: Ensure a privacy notice is available explaining data collection and usage.
- Allow data access: Implement mechanisms for users to request access to their personal data.
- Enable opt-out: Allow users to opt-out of data selling practices if applicable.
HIPAA
- Safeguard protected health information: Implement security measures to protect any health-related data processed.
- Training: Conduct regular training for employees handling sensitive health information.
PCI-DSS
- Secure payment information: Ensure that payment card data is encrypted and stored securely.
- Regular security assessments: Conduct vulnerability scans and penetration testing.
SOX
- Maintain financial data integrity: Implement controls to ensure the accuracy and reliability of financial reporting.
- Audit trails: Maintain detailed logs of all financial transactions.
GLBA
- Protect personal financial information: Implement security measures to safeguard financial data.
- Provide privacy notice: Inform users about the collection and sharing of their financial data.
COPPA
- Parental consent: Obtain verifiable parental consent if collecting data from children under 13.
- Data deletion: Implement processes for removing children’s data upon request.
Data Residency Laws
- Compliance with local laws: Ensure data is stored and processed in accordance with local data protection regulations.
8.3. Data Subject Rights
| Right | Description |
|---|---|
| Right to Access | Users have the right to request access to their personal data. |
| Right to Rectification | Users can request corrections to inaccurate personal data. |
| Right to Erasure | Users can request deletion of their personal data under certain conditions. |
| Right to Restrict Processing | Users can request to limit the processing of their personal data. |
| Right to Data Portability | Users can request to receive their personal data in a structured format. |
| Right to Object | Users have the right to object to the processing of their personal data. |
8.4. Privacy Requirements
Consent: Obtain explicit consent from users for collecting and processing their personal data.
Privacy Notice: Provide clear information about data collection, usage, and rights in a privacy policy accessible to users.
8.5. Audit and Monitoring Requirements
Logging: Maintain comprehensive logs of user access and modifications to personal data.
Audit Trails: Ensure all actions related to data processing are logged for compliance and review purposes.
8.6. Data Handling Rules
Retention: Define a clear data retention policy outlining how long personal data will be stored.
Deletion: Implement processes for the secure deletion of personal data once it is no longer needed.
8.7. Compliance Risk Assessment
As the application will handle sensitive personal data, there are several compliance risks that must be addressed to ensure regulatory adherence and protect user privacy.
Key Compliance Risks:
- Non-compliance with GDPR could lead to substantial fines and reputational damage.
- Failing to protect health information could result in HIPAA violations and penalties.
- Inadequate security controls for financial data could expose the organization to SOX compliance issues.
9. Security Architecture Recommendations
This section provides comprehensive security architecture guidance that integrates security controls into the system’s technical design. Security architecture defines how security principles, controls, and patterns are applied across system components to create a cohesive, defense-in-depth security posture. The recommendations address architectural principles, component-level controls, data protection strategies, and third-party integration security to ensure security is built into the system design.
9.1. Architectural Security Principles
Architectural security principles provide the foundational philosophy guiding all security design decisions. These principles ensure a consistent security posture across all system components and guide the selection and implementation of security controls, balancing security with usability and operational needs.
- Zero Trust Architecture principles: Never trust, always verify — every request (user, device, service) must be authenticated and authorized regardless of network location. This prevents implicit trust of users or systems inside a perimeter and reduces risk from lateral movement.
- Defense in Depth: Deploy multiple complementary layers of protection (network, edge, application, data, identity) so that a failure or bypass of one control is mitigated by others. This improves resilience against diverse attack vectors.
- Principle of Least Privilege: Grant users, services, and components only the minimal permissions required to perform tasks. This reduces blast radius from compromised accounts or services.
- Secure by Default / Secure by Design: Default configurations should be secure (secure TLS, hardened services, minimum open ports). Security requirements must be included from design through development and deployment.
- Separation of Duties: Prevent conflict-of-interest and abuse by ensuring critical tasks (e.g., configuration changes, approval actions, payroll exports) require distinct roles or approval workflows.
- Fail Secure: Systems should default to a safe state on failure — deny access, prevent state corruption, and preserve integrity during outages.
- Complete Mediation: Every access decision must be checked — do not rely on previous authorizations or client-side enforcement; revalidate authorization on each request.
- Immutable Auditability: All lifecycle events required by the application (submissions, approvals, delegation changes, admin amendments, exports) must be logged to tamper-evident, append-only storage to enable effective forensic and compliance activities.
- Privacy by Design & Data Minimization: Collect and expose only the minimum data necessary (e.g., minimize personal data in email notifications) and design features that default to minimum disclosure.
- Defense-in-Depth for Business Logic: Business rules (workweek configuration, min/max hours, delegation scope) must be enforced server-side with policy objects and tested to prevent logic abuse.
9.2. Component-Level Security Controls
Frontend Layer
Required Controls:
- Use secure, short-lived authentication tokens and refresh tokens stored only in secure, HttpOnly, SameSite cookies.
- Enforce client-side input validation and always re-validate server-side.
- Implement Content Security Policy (CSP), X-Frame-Options, X-Content-Type-Options, and HSTS headers.
- Strict handling of PII: do not include sensitive timesheet content in email previews; redact or link to portal.
- Enforce accessibility (WCAG) and privacy-preserving UI patterns (no sensitive data in URL query params).
- Protect against XSS, CSRF (SameSite cookies + anti-CSRF tokens), and clickjacking.
- Transmit no secrets to the client; avoid storing tokens in localStorage/sessionStorage.
- Logging of client-side errors and telemetry to secure endpoint with PII minimization.
- Secure deployment pipeline for frontend artifacts (signed builds, integrity checks).
Recommended Patterns:
- Single Page Application served from CDN with Subresource Integrity (SRI).
- Use OIDC/OAuth2 implicit/PKCE flows appropriate for SPA; prefer Authorization Code + PKCE.
- Local draft autosave encrypted at rest in the browser if persisted; otherwise use server-side draft endpoints.
- Progressive enhancement to ensure accessibility and graceful degradation.
Edge Layer
Required Controls:
- WAF protecting public endpoints with OWASP rules and custom rules for business logic abuse detection.
- CDN for static content delivery with TLS termination and certificate management.
- DDoS protection (rate-based and volumetric) and bot management.
- TLS 1.2+ (prefer TLS 1.3) with strong ciphers and automatic certificate rotation.
- HTTP security header enforcement and response header hardening.
- Rate limiting and IP reputation-based blocking for abusive traffic.
- Logging of request metadata to centralized monitoring with masked PII.
Recommended Patterns:
- API Gateway + WAF fronting the API endpoints to centralize access control and throttling.
- Edge caching with per-route cache controls to avoid exposing private endpoints.
- Geo-IP filtering for admin consoles and management endpoints.
Application Services
Required Controls:
- OAuth2 / OIDC authentication integration with Azure AD; validate issuer, audience, signature, nonce, and expiry.
- Centralized authorization policy engine (RBAC + attribute-based access control combining role + team).
- Server-side enforcement of business rules and state machine for timesheet lifecycle (draft -> submitted -> approved/rejected).
- Input validation, request schema validation, and parameterized DB queries to prevent injection.
- Strong audit logging for all lifecycle events (actor, timestamp, action, resource, previous vs new values).
- Service-to-service mTLS for internal communication or service mesh with mutual authentication.
- Secret management using cloud KMS/KeyVault; no secrets in code or environment variables in plaintext.
- Rate limiting, request throttling, and idempotency for write operations (particularly submissions and approvals).
- Admin actions require MFA and additional approval gating for sensitive amendments.
- Business rule configuration requiring admin role and approval workflow.
- Protection against privilege escalation and horizontal/vertical access bypass.
Recommended Patterns:
- API Gateway with OAuth2 token validation and centralized routing.
- Microservices architecture with bounded contexts (timesheet, approvals, holiday, notification, reporting).
- Policy Decision Point (PDP) / Policy Enforcement Point (PEP) architecture (e.g., OPA) for runtime authorization.
- Service mesh (e.g., managed Istio/Linkerd) for mTLS, observability, and policy enforcement.
- Event-driven async processing (message queue) for notifications and heavy reporting tasks.
Data Storage
Required Controls:
- Encrypted relational database (TDE) and column/field-level encryption for PII and payroll-sensitive fields.
- Immutable, WORM-capable blob storage for audit logs and attachments with access controls.
- Row-level security/label-based access control to enforce team-scoped visibility.
- Fine-grained DB auditing capturing actor, timestamps, queries that change timesheet states.
- Backups encrypted at rest and in transit, with retention and restore procedures tested.
- Database credential rotation and use of managed identity or Key Vault integration.
- Data masking for sensitive fields in non-production environments; synthetic data for testing.
- Periodic integrity checks and checksums on audit logs; signing of audit records if required.
- Use of managed cache (Redis) with network isolation and authentication; do not persist sensitive PII in cache without encryption.
Recommended Patterns:
- Encrypted RDBMS with Transparent Data Encryption and Column-Level Encryption / Always Encrypted for SSN or payroll identifiers.
- Immutable blob containers for audit logs with retention policies (time-based WORM).
- Use DB-level Row-Level Security (RLS) and views to enforce team-based filtering.
- Secrets in KeyVault; DB connections use managed identities.
Integration & External Services
Required Controls:
- Secure integration with Azure AD (OIDC/SAML) for user authentication and SCIM for provisioning where available.
- Secure email/transactional provider usage over TLS and avoid embedding sensitive data in emails.
- Secure channels for HR/payroll exports (mTLS, SFTP with key authentication, or OAuth with client credentials).
- Signed payloads and integrity verification for external public holiday feeds.
- Enforce least privilege service accounts and per-integration credentials rotated regularly.
Recommended Patterns:
- Use OAuth2 client credentials for server-to-server API integrations where supported.
- Use managed connectors with conditional access and named service principals.
- Logging and monitoring of integration activity, error rates, and unexpected changes.
- Input validation and schema verification for inbound external data.
Operational Services
Required Controls:
- Centralized SIEM for logging and alerting; logs protected with strict access control and immutable retention for audit events.
- Monitoring and alerting for suspicious activity (anomalous approvals, mass exports, repeated failed logins).
- Backup and recovery plans, tested RTO/RPO, and secure deletion/sanitization procedures.
- Privileged Access Management (PAM) for admin accounts and just-in-time (JIT) elevation.
- Vulnerability management, patching, and configuration management for all nodes and services.
- Secure CI/CD pipeline with pipeline secrets in KeyVault and build artifact signing.
Recommended Patterns:
- Role-based access to operational consoles with MFA and session timeouts.
- Automated playbooks for incident response and runbooks for administrative high-impact changes.
- Use of endpoint protection (EDR) and managed detection services for platform hosts.
9.3. Data Protection Strategy
Data Classification: Public, Internal, Confidential, Restricted
- Public: Non-sensitive user interface content, generic product information.
- Internal: Operational metadata, non-sensitive telemetry, UI preferences.
- Confidential: User profiles, team hierarchy, timesheet entries (hours, project codes), holiday balances, non-sensitive attachments.
- Restricted: Payroll export data, personally identifying information (PII) with regulatory constraints (e.g., SSNs), approved audit logs for legal purposes.
Encryption Requirements:
- Data in transit: TLS 1.2 minimum, TLS 1.3 preferred. Enforce strong ciphers (AEAD suites), disable TLS 1.0/1.1, and enable HSTS. Use OIDC token validation with signature checks.
- Data at rest (database and blob): AES-256-GCM (or equivalent) for full-disk/TDE and envelope encryption patterns. Use cloud provider KMS/HSM (e.g., Azure Key Vault with HSM-backed keys).
- Field/column-level encryption: Use “Always Encrypted” or equivalent for highly sensitive fields (SSN, payroll identifiers) with client-side or DB-native column encryption.
- Audit log integrity: Use chained hashes or HMAC-SHA256 signatures per log block; store signed audit records in WORM blob storage.
- Key lengths and algorithms: RSA 3072 or better for asymmetric operations; ECC (P-256 or P-384) acceptable for signing; AES-256 for symmetric encryption; SHA-256+ for hashing; use approved provider-managed HSM for key operations.
- Key management: Keys stored in Key Vault/HSM, role-based access to keys, periodic key rotation (e.g., annual, or as required), and close monitoring of key use. Use separate keys for different data domains (audit logs, backups, PII).
Retention Policies:
- Timesheets and submission records: retain per legal and business requirements (e.g., 7 years recommended for payroll/audit, configurable per region). Document retention justification.
- Audit logs: retain immutable logs per compliance needs (e.g., 7-10 years) in WORM storage with integrity verification.
- Holiday requests and balance history: retain at least as long as employment + statutory requirements for HR (region-specific).
- Backups: retain according to retention schedule with encrypted backups; implement retention expiry and secure deletion/purgation.
- Purging: Implement authorized purge workflows (admin/HR with approval) and record purge events in audit logs. Ensure backups also honor purge (or maintain legal holds when required).
Handling Procedures:
- Access:
- Enforce RBAC and ABAC (role + team attributes) for all data requests.
- Data access requests for exports require authorization, logging, and approval.
- Limit admin privileges via PAM and JIT elevation.
- Transmission:
- All transmission of confidential/restricted data must use TLS and authenticated channels (mTLS for server-to-server where possible).
- Email notifications should not include detailed timesheet PII; include links requiring portal authentication.
- Storage:
- Store attachments in blob storage with per-object ACLs; sensitive attachments are encrypted with separate keys and flagged for retention rules.
- Cache only ephemeral UI data; never cache full PII or payroll-sensitive datasets in shared caches. If caching is necessary, use encryption and TTLs.
- Deletion:
- Implement secure delete workflows: logical deletion flagged in DB, followed by physical purge following retention expiry. Audit all deletion events.
- Ensure deletion propagates to backups consistent with legal holds.
- Data Export:
- Exports to HR/payroll must be encrypted in transit (SFTP with keys, mTLS, or encrypted API payloads).
- Exports must be logged, with actor, timestamp, scope, purpose, and checksum.
- Require approval for exports involving restricted classifications.
- Non-production:
- Use data masking or synthetic data in dev/test environments; restrict access to any production data used in analysis to authorized staff only.
- Monitoring:
- Monitor data access patterns and create alerts for anomalous access (e.g., mass reads of timesheets, repeated export attempts).
9.4. Third-Party Integration Security
Azure AD (Identity Provider & SCIM/SSO)
Security Requirements:
- Validate OIDC/SAML assertions, issuer, audience, and signature.
- Use OAuth2 Authorization Code + PKCE for SPAs and server-side flows for backend.
- Apply conditional access policies and require MFA for privileged roles.
- Use SCIM or provisioning APIs for synchronized account lifecycle management.
- Use separate service principals for different application components.
Risk Assessment: Critical - Authentication is foundational; any compromise could enable broad impersonation and large-scale data exposure.
Recommended Controls:
- Enforce token validation (nonce, exp, aud, iss) and claim checks in backend.
- Use Azure AD conditional access (MFA for admin and privileged flows).
- Use managed identities for services and restrict application registration permissions.
- Monitor sign-ins and configure alerts for anomalous logins and token misuse.
Email / Transactional Provider
Security Requirements:
- Use TLS for SMTP/API transport.
- Authenticate via API keys or OAuth with scoped permissions.
- Avoid sending sensitive data in email bodies; use portal links instead.
- Store credentials in Key Vault and rotate regularly.
Risk Assessment: High - Email exposure can leak sensitive notifications and enable social engineering.
Recommended Controls:
- Use vendor API with TLS and IP allowlisting where supported.
- Apply strict template content controls; redact PII.
- Monitor bounce/failure rates and set alerts on unusual volumes.
- Sign emails (DKIM) and enforce SPF/DMARC to reduce spoofing.
HR/Payroll API (Optional Export Integration)
Security Requirements:
- Strong authentication: OAuth2 client credentials or mTLS.
- Minimum-privilege service account with scoped export permissions.
- Payload signing and integrity verification.
- Audit trail of all exports.
Risk Assessment: Critical - Contains payroll-sensitive data requiring confidentiality and integrity; regulatory implications.
Recommended Controls:
- Use mTLS or OAuth2 with short-lived client credentials.
- Encrypt export files at rest and transit; include HMAC or digital signature.
- IP allowlisting and rate limiting for export endpoints.
- Require approval workflow prior to export and log the operation.
CDN / WAF / DDoS Provider
Security Requirements:
- TLS termination with strong cipher suites.
- WAF rules updated for OWASP Top 10 and custom business logic rules.
- DDoS mitigation and traffic scrubbing.
Risk Assessment: High - Provider outage or misconfiguration can cause downtime and potential traffic interception risks.
Recommended Controls:
- Enforce SNI and TLS policies; use managed certificates with automatic rotation.
- Apply custom WAF rules for timesheet APIs to block business logic abuse.
- Monitor alerts and integrate with incident response playbooks.
Public Holiday Feed Provider
Security Requirements:
- Source signed or authenticated feeds (HTTPS with certificate validation).
- Versioned datasets with checksums; signed payloads preferred.
- Admin-only interfaces for overriding/patching holiday data.
Risk Assessment: Medium - Integrity issues could affect leave calculations and business rules; lower confidentiality risk.
Recommended Controls:
- Validate feed checksums and timestamps; maintain dataset versioning and rollback capability.
- Restrict modification of holiday data to admin roles with approvals.
- Log changes and keep an audit trail of dataset imports.
Message Queue Provider (Async Notifications & Reporting)
Security Requirements:
- Use private network connectivity (VNet), SAS tokens or mTLS for authentication.
- Enforce per-queue permissions and role-based access.
- Encrypt messages at rest and in transit.
Risk Assessment: Medium - Messages can contain timesheet metadata; compromise could lead to data leakage or message tampering.
Recommended Controls:
- Use managed queue services with RBAC and encryption.
- Monitor queue metrics and dead-letter queues for anomalies.
- Apply message signing or integrity checks for critical workflows.
Cloud RDBMS Provider
Security Requirements:
- Network isolation (private endpoints), encryption at rest (TDE) and in transit, auditing.
- Role-based DB accounts and managed identities.
Risk Assessment: Critical - Principal data store for timesheets and PII; misconfiguration can lead to major breaches.
Recommended Controls:
- Use private endpoints and firewall rules limiting access.
- Require SSL/TLS for DB connections and enforce server certificate validation.
- Enable DB auditing and threat detection services.
Cloud Blob Storage Provider (Attachments & Immutable Audit)
Security Requirements:
- Enforce container-level ACLs, encryption at rest with customer-managed keys (CMK), WORM/immutability for audit containers.
- SAS tokens with minimal scope and expiry; monitor token use.
Risk Assessment: High - Contains immutable audit logs and potentially sensitive attachments.
Recommended Controls:
- Use WORM-enabled containers for audit logs and enforce retention policies.
- Monitor access logs and set alerts for unusual retrievals.
- Use separate keys for audit storage and attachments.
Monitoring / Logging / SIEM Provider
Security Requirements:
- TLS for log ingestion, RBAC for log access, immutable storage for critical audit data.
- Integration with identity provider for access and SSO.
Risk Assessment: High - Contains sensitive operational and security data; improper access can hamper investigations.
Recommended Controls:
- Restrict log access to security/ops roles and enable MFA.
- Protect log integrity (append-only, signed logs) and maintain retention.
- Correlate audit trails and create anomaly detection rules for approvals, exports, and delegation changes.
(End of document)
10. Implementation Roadmap
This section provides a prioritized, phased approach for implementing the security controls identified throughout this analysis. The roadmap organizes security measures into logical phases based on risk, dependencies, and resource availability, ensuring critical security gaps are addressed first while building a foundation for comprehensive security coverage.
10.1. Prioritization Framework
Prioritization is crucial for effective security implementation as it ensures that resources are allocated efficiently to address the most pressing threats and compliance requirements first. This approach minimizes potential security breaches and ensures regulatory compliance, thereby protecting the organization from potential legal and financial repercussions.
Prioritization Criteria:
Risk Level: Controls addressing critical and high-risk threats (identified through threat modeling) are prioritized first
Compliance Deadlines: Regulatory requirements and compliance deadlines influence immediate priority
Technical Complexity: Controls requiring foundational infrastructure are implemented early to enable subsequent controls
Dependencies: Controls that other security measures depend upon are prioritized accordingly
Resource Availability: Implementation considers the availability of skilled personnel, tools, and budget
Business Impact: Controls protecting business-critical functions and data receive higher priority
These criteria work together to create a logical implementation sequence that balances security needs with practical constraints, ensuring that critical vulnerabilities are addressed immediately while allowing for strategic, long-term planning.
10.2. Phased Implementation Plan
Phase: IMMEDIATE
Timeline: 0-1 months
Rationale: This phase addresses critical vulnerabilities and compliance blockers that pose the highest risk to the organization if left unaddressed.
Controls to Implement:
Implement role-based access control (RBAC) for all user roles to prevent unauthorized access
Enforce server-side validation and business rules for timesheet entries to prevent data tampering
Enable basic encryption for sensitive data in transit and at rest to protect personal information
Configure Azure SSO with strong authentication settings and conditional access policies
Establish an immutable audit logging solution to ensure accountability and traceability of actions
Dependencies:
Completion of Azure SSO configuration
Implementation of basic encryption infrastructure
Phase: SHORT-TERM
Timeline: 1-3 months
Rationale: These controls build upon immediate security measures, focusing on improving access control adjustments and ensuring that logging and API security mitigate identified threats effectively.
Controls to Implement:
Enhance user authentication through comprehensive multi-factor authentication
Deploy role-based access controls across the admin dashboard
Implement comprehensive logging and monitoring for all administrative actions
Strengthen API security with input validation and HTTPS protocols
Begin encryption for all sensitive data at rest
Dependencies:
Completion of TLS Implementation
Completion of multi-factor authentication
Phase: MEDIUM-TERM
Timeline: 3-6 months
Rationale: Focus on implementing advanced security measures and conducting thorough security assessments to identify and address potential vulnerabilities.
Controls to Implement:
Deploy advanced threat detection systems to identify and respond to emerging threats
Automate security testing within the development lifecycle
Conduct third-party security audits to ensure compliance with regulatory standards
Enhance data protection measures for personal and financial information
Dependencies:
Full implementation of comprehensive logging and monitoring
Completion of API security enhancements
Phase: LONG-TERM
Timeline: 6-12 months
Rationale: This phase aims to enhance the organization’s security maturity and resilience through strategic initiatives.
Controls to Implement:
Develop and implement security awareness programs for employees
Integrate advanced AI/ML security controls for predictive threat detection
Conduct comprehensive penetration testing to identify and mitigate vulnerabilities
Continuously improve security processes and technologies
Dependencies:
Completion of advanced threat detection deployment
Establishment of security testing automation
Phase: ONGOING
Timeline: Continuous
Rationale: Maintain a proactive security posture through regular monitoring, audits, and incident response readiness.
Controls to Implement:
Continuous security monitoring and analysis
Regular patch management to address vulnerabilities
Conduct periodic compliance audits to ensure regulatory adherence
Maintain incident response readiness and conduct regular drills
10.3. Resource Requirements
Skills: Security engineers, Security architects, Web developers, Compliance specialists
Recommended tools: SIEM solutions for logging and monitoring, Vulnerability scanners for testing, Encryption libraries for data protection, API management tools for secure interfaces
Estimated time effort: Approximately 3-6 months for initial phases, with ongoing efforts extending resources as per system complexity and requirements.
11. Verification and Testing Strategy
11.1. Testing Approach
Integrate security testing throughout the software development lifecycle (SDLC) with an emphasis on continuous security practices. Balance automated scanning with manual evaluations to prioritize high-risk areas based on business impact, adhering to shift-left security principles by incorporating security testing earlier and continuously. This approach ensures that security is an integral part of development and operations, significantly reducing the risk of vulnerabilities in production.
11.2. Testing Methods
| Method | Frequency | Tools |
|---|---|---|
| STATIC APPLICATION SECURITY TESTING (SAST) | Every commit/build | SonarQube, Semgrep, Checkmarx, CodeQL |
| DYNAMIC APPLICATION SECURITY TESTING (DAST) | Nightly/weekly | OWASP ZAP, Burp Suite, Acunetix |
| DEPENDENCY SCANNING | Every build | Snyk, Dependabot, OWASP Dependency-Check |
| SECRETS SCANNING | Every commit | TruffleHog, GitLeaks, GitHub Secret Scanning |
| CONTAINER/INFRASTRUCTURE SCANNING | Every deployment | Trivy, Clair, Prowler, ScoutSuite |
| PENETRATION TESTING | Quarterly or before major releases | Custom scripts, Metasploit, Burp Suite Pro |
| SECURITY CODE REVIEW | For critical features | GitHub/GitLab code review, Security checklists |
| COMPLIANCE SCANNING | Continuous | AWS Config, Azure Policy, Cloud Custodian |
11.3. Compliance Verification
Multi-standard compliance (OWASP ASVS, NIST SP 800-53, ISO 27001) will be verified through automated tools and manual checks against regulatory requirements such as GDPR, CCPA, and PCI-DSS. Compliance controls will be mapped against each applicable regulation, and audit preparation will involve ensuring documentation and evidence collection for external audits. Recommendations will include engaging third-party auditors for comprehensive evaluations to validate adherence to regulations and enhance the overall security posture.
11.4. Continuous Monitoring
Implement Security Information and Event Management (SIEM) for real-time monitoring, supported by Intrusion Detection/Prevention Systems (IDS/IPS) to identify and mitigate threats. All logs will be aggregated and analyzed for anomalies, with integration into incident response processes to ensure prompt action against security events. Continuous monitoring will also include alerts for unusual activities and compliance violations, facilitating swift remediation and ongoing risk assessment.
11.5. Key Performance Indicators (KPIs)
- Mean time to detect (MTTD) security issues
- Mean time to remediate (MTTR) vulnerabilities
- Percentage of critical vulnerabilities patched within SLA
- Security test coverage percentage
- False positive rate in automated scanning
- Compliance audit pass rate
12. Validation Report
This section presents a comprehensive validation of the security requirements generated throughout this analysis. The validation evaluates the requirements against five key dimensions: completeness, consistency, correctness, implementability, and alignment with business objectives. This assessment ensures that the security requirements are comprehensive, technically sound, and actionable for implementation teams.
12.1. Overall Assessment
The overall validation score reflects the quality and completeness of the security requirements across five critical dimensions. Each dimension is scored from 0.0 to 1.0, with 1.0 representing excellent coverage and 0.0 indicating significant gaps.
Overall Score: 0.84/1.0
Validation Status: ✅ PASSED
The security requirements have met the quality threshold (≥0.8) and are ready for implementation. The requirements demonstrate comprehensive coverage, technical accuracy, and alignment with business objectives.
The validation assesses:
- Completeness: Are all identified security concerns adequately addressed?
- Consistency: Do requirements align with each other without contradictions?
- Correctness: Are controls appropriate for the identified risks and correctly applied?
- Implementability: Are requirements specific, actionable, and feasible to implement?
- Alignment: Do security requirements align with business requirements and objectives?
12.2. Dimension Scores
| Dimension | Score | Status |
|---|---|---|
| Completeness | 0.80 | ✅ |
| Consistency | 0.90 | ✅ |
| Correctness | 0.90 | ✅ |
| Implementability | 0.75 | ⚠️ |
| Alignment | 0.85 | ✅ |
Score Interpretation: - ✅ 0.8-1.0: Excellent - ⚠️ 0.7-0.79: Acceptable (minor improvements needed) - ❌ <0.7: Needs significant improvement
12.3. Detailed Feedback
Implementability
- For each high-level control, add owner, priority (MUST/SHOULD), acceptance criteria, and at least one test case. - Provide a small, prioritized backlog of MUST-have security stories for the initial release (MFA for admins, server-side RBAC enforcement, audit logging with tamper-evidence, TLS/encryption at rest, CSRF protections, SSO token validation) and a roadmap for SHOULD/optional items (PAM, advanced analytics monitoring). Overall conclusion: The design is solid and aligns with business needs, but to be fully actionable and lower residual risk, add explicit, measurable requirements in the areas above (session/SSO specifics, MFA and privileged access, log tamper-evidence, web attack protections, integration auth, retention/DSAR procedures, and operational security).
Appendix A: Original Requirements Document
Timesheet Website Requirements
We need to build a web application for employees to track work hours, submit timesheets for approval, and manage holiday requests.
Key Features:
1. User Roles
- Employee: Create, view, and submit weekly timesheets; enter hours per day with project/task codes; request and record holiday; view holiday balance and historical timesheets
- Manager: View and approve or reject employee timesheets; view team members' timesheet history and holiday usage; assign delegates for approval
- Delegate: Perform manager approval tasks for specific periods
- Administrator: Configure system-wide settings (workweek rules, public holidays, user management); configure working patterns; view audit logs; amend timesheets after submission
2. Timesheet Entry
- Enter hours worked per day, per week, with support for multiple tasks/projects
- Save draft before submission
- Prevent submission until all required fields are completed
- Track total weekly hours and enforce minimum/maximum limits if configured
3. Timesheet Submission and Approval
- Submit weekly timesheets for approval
- Record submission timestamp
- Timesheets become read-only after submission unless rejected
- Managers approve or reject with comments
- Approval/rejection actions logged with time and identity
4. Holiday & Leave Management
- Request holiday days within timesheet or dedicated interface
- Holidays automatically populate in timesheet week as non-working hours
- Track remaining leave balance per user
- Managers approve or reject holiday requests
- Preload public holidays and auto-apply to relevant days
5. Manager Delegation
- Assign delegates authorized to approve timesheets
- Delegation includes start/end dates and scope of permissions
- Delegates receive same notifications for approval tasks
- Managers can revoke delegation at any time
6. Notifications
- Email notifications for timesheet submission reminders
- Notifications for timesheet approval needed
- Approval or rejection confirmations
- Delegation change notifications
7. Reporting
- Weekly, monthly, and custom time reports for employees and managers
- Audit logs capturing timesheet creation/updates, submissions, approvals/rejections, and delegation changes
8. System Requirements
- Responsive design for desktop, tablet, and mobile
- Accessible UI compliant with WCAG guidelines
- Integration with Azure SSO for authentication
The application will store user data, timesheet entries, holiday requests, approval workflows, and audit logs. Data access is restricted based on team hierarchy.
Appendix B: Glossary
| Term | Definition |
|---|---|
| ASVS | Application Security Verification Standard (OWASP) |
| STRIDE | Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege |
| SAST | Static Application Security Testing |
| DAST | Dynamic Application Security Testing |
| MFA | Multi-Factor Authentication |
| RBAC | Role-Based Access Control |
| PII | Personally Identifiable Information |
| PHI | Protected Health Information |
| GDPR | General Data Protection Regulation |
| HIPAA | Health Insurance Portability and Accountability Act |
| PCI-DSS | Payment Card Industry Data Security Standard |
Appendix C: Complete Threat List
This appendix contains the complete list of all identified threats with full descriptions and mitigation strategies. Threats are organized by risk level for easy reference.
Critical Risk Threats
THR-003 - Timesheet Entry / Frontend & API
- Category: Tampering
- Likelihood: High | Impact: High
- Risk Level: Critical
- Description: A malicious user manipulates client-side data (e.g., via browser devtools, intercepted requests, or a scripted client) to submit falsified timesheet hours, change project/task codes, or bypass required-fields checks resulting in fraudulent payroll/exported data.
- Mitigation Strategy: Enforce all validation and business rules server-side (required fields, min/max hours, project permissions). Implement strong authorization checks for project/task assignment. Log all changes with user identity and timestamps. Use anomaly detection on submitted hours and require manager validation for outliers.
High Risk Threats
THR-001 - Integration & External Services / Frontend / Application Services (Azure AD SSO tokens)
- Category: Spoofing
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, token theft, or compromised device) and impersonates employees/managers to submit or approve timesheets, view other users’ data, or change configuration.
- Mitigation Strategy: Enforce strong Azure AD configuration: require MFA/conditional access, short token lifetimes, refresh token rotation, device compliance checks, detect anomalous sign-ins, revoke tokens on suspicious activity. Implement session management and token binding where possible. Monitor and alert on unusual approval activity.
THR-004 - Application Services (Approval API)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: An attacker modifies API requests (parameter tampering) to set approval fields (e.g., approved=true) or change timesheet status without proper authorization checks, enabling unauthorized approvals or status changes.
- Mitigation Strategy: Implement server-side authorization checks (verify caller identity & role), require explicit manager identity verification for approval endpoints, enforce immutability of submitted timesheets unless a documented reject/amend flow exists, and validate every state transition with business rules.
THR-005 - Data Storage / Operational Services (Audit logs)
- Category: Repudiation
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Insufficient or modifiable audit logging allows users (or attackers) to deny actions or to remove traces of malicious changes (e.g., approvals, delegation changes) so incidents cannot be proven.
- Mitigation Strategy: Store audit logs in tamper-evident/immutable storage (WORM), sign logs, use append-only streams, forward logs to an external SIEM, protect log ingestion credentials, and implement strict access control and monitoring for log access.
THR-007 - Data Storage (Relational DB / Blobs)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Data stored without proper encryption or network isolation is exposed via cloud console compromise, misconfigured storage ACLs, or stolen backups leading to leakage of user profiles, timesheets, and balances.
- Mitigation Strategy: Encrypt data at rest (managed keys or HSM), enable network isolation (private endpoints, VNet), enforce least-privilege IAM for DB and storage, rotate keys, and regularly scan for publicly exposed buckets/containers.
THR-008 - Application Services (APIs enforcing team hierarchy)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Broken access control or misapplied team hierarchy rules cause the API to return timesheet or holiday data to unauthorized users (e.g., employees viewing other teams’ data).
- Mitigation Strategy: Implement robust RBAC/ABAC policies, verify team membership server-side on every request, use least privilege, automated access-control unit tests, and perform periodic access reviews and penetration testing focused on horizontal data access.
THR-009 - Application Services / Operational Services (Administrator accounts)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Administrator (or admin API credential) compromise permits system-wide configuration changes (workweek rules, audit log deletion or view), user management abuse, or backdoor creation.
- Mitigation Strategy: Protect admin accounts with stronger controls: enforced MFA, privileged identity management (just-in-time elevation), segmented admin interfaces, audit of admin actions, and strict approval/workflow for admin changes.
THR-010 - Edge Layer (CDN/WAF/DDoS)
- Category: Denial of Service
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Volumetric or application-layer DDoS against the CDN/WAF or API gateway causes service disruption preventing users from submitting/approving timesheets or accessing holiday requests.
- Mitigation Strategy: Enable cloud provider DDoS protection, autoscaling, WAF rate rules, geo-blocking for suspicious traffic, traffic scrubbing, and runbook for failover and communication. Test resilience regularly.
THR-012 - Integration & External Services (Email)
- Category: Spoofing
- Likelihood: High | Impact: Medium
- Risk Level: High
- Description: Attackers send spoofed emails resembling system notifications (approval requests or delegation changes) to trick users into clicking malicious links or divulging credentials.
- Mitigation Strategy: Publish and enforce SPF/DKIM/DMARC for sending domains, include secure link patterns, educate users on phishing, include in-app verification of actions, and consider signed emails or HMACed notification tokens.
THR-013 - Frontend Layer (SPA) / Application Services (API responses)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Stored or reflected XSS in the SPA exposes authentication cookies, tokens, or visible sensitive data, allowing account takeover or data leakage.
- Mitigation Strategy: Implement output encoding, input validation, Content Security Policy (CSP), use httpOnly and secure cookie flags, sanitize HTML and third-party content, and perform SAST/DAST focused on XSS.
THR-019 - Manager Delegation / Data Storage
- Category: Spoofing
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: An attacker modifies delegation records (direct DB write or API tampering) to make themselves or a malicious user a delegate, allowing approvals and access to team timesheets.
- Mitigation Strategy: Restrict delegation changes to authenticated manager flows with two-factor confirmation for delegation grants, send email/ in-app notifications for delegation creation, enforce server-side validation of who can create delegations, and audit delegation changes.
THR-021 - Application Services (API/DB)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: SQL injection or other injection vulnerabilities in APIs allow attackers to modify or view database entries including timesheets, user data, or audit records.
- Mitigation Strategy: Use parameterized queries/ORM, input validation and whitelisting, enforce least-privilege DB accounts, use WAF signatures as defense-in-depth, and run automated SAST/DAST and regular penetration testing.
THR-022 - Data Storage (Backups / Cloud storage)
- Category: Information Disclosure
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Misconfigured backups or snapshots (publicly accessible storage or weak ACLs) expose complete datasets including PII and payroll-relevant timesheet records.
- Mitigation Strategy: Restrict backup storage to private networks, enforce encryption, audit and monitor storage ACL changes, automate scanning for public buckets, and secure backup management credentials.
THR-024 - Application Services (Authorization / RBAC)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Broken access control (e.g., insecure direct object references or missing checks) allows regular employees to view or approve timesheets for other teams, leading to fraud and privacy breach.
- Mitigation Strategy: Enforce per-request authorization checks, avoid client-provided identifiers for access decisions, implement ABAC where appropriate, write comprehensive authorization tests, and perform regular access control audits and pentests.
THR-026 - Edge Layer / Frontend (CDN delivered JS)
- Category: Tampering
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Compromise of CDN or supply chain leads to malicious JavaScript being served to clients, enabling credential theft, XSS, or DOM-based manipulation of timesheet data.
- Mitigation Strategy: Use Subresource Integrity (SRI), pin dependencies, host critical JS from trusted origins or inline critical code, monitor CDN integrity, enable automated dependency scanning, and employ CSP to limit impacts.
THR-027 - Edge Layer / Application Services (TLS termination)
- Category: Information Disclosure
- Likelihood: Low | Impact: High
- Risk Level: High
- Description: Weak or misconfigured TLS (old ciphers, expired certs, no HSTS) allows man-in-the-middle attacks to intercept tokens or timesheet data in transit.
- Mitigation Strategy: Enforce TLS 1.2+ (prefer 1.3), disable weak ciphers, implement HSTS, use managed certificate services, monitor certificate expiry, and encrypt internal service-to-service traffic.
THR-029 - Operational Services / Data Storage (Insider threat)
- Category: Denial of Service
- Likelihood: Low | Impact: High
- Risk Level: High
- Description: Insider (malicious or compromised admin) deletes or rolls back audit logs, backups, or critical configuration leading to loss of integrity or availability of forensic evidence.
- Mitigation Strategy: Use immutable backups/WORM for audit logs, enforce separation of duties, restrict admin operations via privileged access management, alert on mass deletes/backup changes, and maintain off-site/offline copies.
THR-030 - Integration & Data Storage (Cloud IAM & managed identities)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: High
- Risk Level: High
- Description: Misconfigured cloud IAM roles or overly-permissive managed identities allow services or users to gain higher privileges (e.g., DB admin), leading to data exfiltration or system takeover.
- Mitigation Strategy: Apply least-privilege IAM policies, use managed identities with limited scopes, periodically review roles and permissions, implement role-approval workflows, and monitor IAM changes with alerts.
Medium Risk Threats
THR-002 - Frontend Layer / Application Services (JWT/session handling)
- Category: Spoofing
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Session fixation or manipulation of client-side tokens (JWT tampering) leading to unauthorized access if signatures aren’t verified or token claims aren’t validated server-side.
- Mitigation Strategy: Use signed JWTs with server-side validation, short token TTL, secure storage (httpOnly, secure cookies), token revocation lists, refresh token rotation, and reject tokens with tampered claims. Validate token audience/issuer/nonce.
THR-006 - Integration & External Services (Email notifications)
- Category: Information Disclosure
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Sensitive timesheet or personnel data is leaked via email notifications (e.g., detailed timesheet contents, manager comments), exposing PII or other sensitive information to unintended recipients or through insecure email transport.
- Mitigation Strategy: Minimize content in emails (use placeholders and secure links to the app), avoid PII in email bodies, enforce TLS for SMTP/API, redact sensitive fields, and support expiring secure links for details. Document email templates and review for leakage.
THR-011 - Application Services / Message Queue
- Category: Denial of Service
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: API abuse or lack of rate limiting causes queue/backlog storm (notification/reporting jobs), exhausting resources and delaying critical approval or reporting operations.
- Mitigation Strategy: Enforce API rate limiting and quotas per user/tenant, backpressure and circuit breaker patterns, prioritize critical jobs, and implement monitoring/alerts for queue depths.
THR-014 - Data Storage (Blob attachments)
- Category: Tampering
- Likelihood: Low | Impact: Medium
- Risk Level: Medium
- Description: An attacker replaces or tampers with uploaded attachments (e.g., receipts, evidence) stored in blob storage, undermining audit integrity or providing falsified evidence.
- Mitigation Strategy: Enable immutable (WORM) storage or versioning for attachments, use signed URLs with narrow time windows, store checksums/hashes in DB, and log upload/replace actions with identity.
THR-015 - Application Services / Operational Services (Audit & Approval)
- Category: Repudiation
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Manager or delegate claims they did not approve/reject a timesheet because audit trails lack signed identity/timestamp or the system allows anonymous approvals via email links.
- Mitigation Strategy: Record full identity and context for approvals (user id, auth token claims, IP, device), avoid email-only approval without in-app confirmation, and timestamp + sign approval events. Retain logs in immutable storage and backup.
THR-016 - Manager Delegation (Application Services)
- Category: Elevation of Privilege
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: A delegate uses delegated permissions beyond the defined scope or after the delegation expiry (e.g., approving for the wrong team or outside date range).
- Mitigation Strategy: Enforce delegation scope and start/end validation server-side for every approval attempt, notify original manager and delegate on delegation changes, log all delegated actions, and provide an audit and revoke capability.
THR-017 - Application Services (Business rules engine)
- Category: Tampering
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Misconfiguration or unauthorized modification of business rules (e.g., min/max hours, public holidays) leads to incorrect enforcement, allowing overworked/underworked entries or bypassing holiday application.
- Mitigation Strategy: Protect configuration change paths with RBAC, require approval and audit for business rule changes, validate rule changes in staging with automated tests, and provide immutable history of rule versions.
THR-018 - Operational Services (Monitoring & Logs)
- Category: Information Disclosure
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Debug or verbose logs in production include tokens, PII, or timesheet content which are accessible to engineering or third-party monitoring tools, leading to data exposure or leakage.
- Mitigation Strategy: Implement logging policy to redact PII and secrets, use structured logging with redaction, restrict access to logs by role, and configure monitoring/third-party integrations to avoid ingesting sensitive data.
THR-023 - Application Services / Notifications (Message Queue)
- Category: Denial of Service
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Maliciously or accidentally triggering large-scale notifications (e.g., mass delegation or submission events) overwhelms the notification service or queue, delaying or dropping critical messages.
- Mitigation Strategy: Implement per-user/event rate limiting for notifications, batching, queuing limits, backpressure handling, and monitoring with alerts for queue saturation. Use retry/backoff strategies.
THR-025 - Frontend Layer / Application Services (CSRF vector)
- Category: Tampering
- Likelihood: Medium | Impact: Medium
- Risk Level: Medium
- Description: Cross-Site Request Forgery (CSRF) allows a remote site to trigger manager actions (e.g., approve a timesheet) if the app relies solely on cookies without CSRF protections.
- Mitigation Strategy: Use anti-CSRF tokens or SameSite=strict cookies, require double-submit cookies or origin checks for state-changing requests, and avoid unsafe methods with cookie-based auth for sensitive operations.
THR-028 - Integration & External Services (Transactional Email provider)
- Category: Repudiation
- Likelihood: Low | Impact: Medium
- Risk Level: Medium
- Description: Transactional email provider fails to provide reliable delivery receipts or manipulates logs, creating gaps that make it difficult to prove notifications were sent or received.
- Mitigation Strategy: Keep local audit logs of notification events, store delivery statuses from the provider, choose reputable providers with immutable logs/features, and have fallback notification channels (in-app/SM S).
Low Risk Threats
THR-020 - Integration & External Services (Public holiday feeds)
- Category: Information Disclosure
- Likelihood: Low | Impact: Low
- Risk Level: Low
- Description: A malicious or compromised public holiday feed provides malformed or malicious data, or leaks organization-specific mappings causing incorrect holiday application or confusion in timesheets.
- Mitigation Strategy: Validate and sanitize external feed data, sandbox import process, apply whitelist rules, and allow administrators to approve feed changes. Monitor for anomalies and fallback to cached known-good data.
Total Threats: 30
Appendix D: Complete Requirements Traceability Matrix
This appendix provides complete end-to-end traceability from requirements through threats to controls and verification.
Full Traceability Table
| Req ID | Requirement | Category | Sensitivity | Threat IDs | Security Controls | Priority | Verification | Status |
|---|---|---|---|---|---|---|---|---|
| REQ-001 | Role-based access control with Employee, Manager, … | User Management / Authorization | High | THR-001, THR-002, THR-008 +7 | [NIST] AC-02, [ISO27001] A.9.1.2, [OWASP] ASVS 2.1 | Critical | Code review of authorization checks, automated tests simulating role-based access attempts, and penetration testing for role escalation vulnerabilities., Review account management procedures, inspect role assignment workflows, and test create/modify/disable/delete operations for each role; verify role enforcement in code and access control lists. | Pending |
| REQ-002 | Integrate with Azure SSO for authentication and su… | Authentication | High | THR-001, THR-013, THR-015 +1 | [OWASP] ASVS 2.3, [NIST] IA-08, [ISO27001] A.9.4.2 | Critical | Validate configuration against Azure AD metadata, test sign-on flows for multiple scenarios (fresh login, SSO, logout), and review IdP trust settings., Review secure logon procedure documentation, test SSO flows for MFA and session handling, and confirm configuration meets organizational security requirements. | Pending |
| REQ-003 | User management and team hierarchy mapping to assi… | User Management / Data Management | High | THR-001, THR-003, THR-005 +7 | [NIST] AC-02, [ISO27001] A.9.2.2, [OWASP] ASVS 2.5 | Critical | Review provisioning workflow documentation, sample user profiles for correct team/manager attributes, and examine periodic access review records., Code and configuration review of account management APIs, functional tests for reassigning managers/delegates, and logs verifying change history. | Pending |
| REQ-004 | Daily and weekly timesheet entry supporting multip… | Timesheet Management / Data Entry | Medium | THR-001, THR-003, THR-004 +7 | [NIST] SI-12, [OWASP] ASVS 5.1, [NIST] AU-12 | Critical | Functional testing of timesheet workflows, review test coverage for multiple projects/tasks, and validate business rule enforcement during entry., Inspect logs and entries to confirm user attribution fields are recorded and cannot be altered by normal users. | Pending |
| REQ-005 | Save draft timesheets locally/server-side and prev… | Data Validation / UX | Low | THR-001, THR-003, THR-004 +7 | [OWASP] ASVS 5.3, [NIST] SI-10, [ISO27001] A.14.2.5 | Critical | Attempt to submit incomplete drafts via API, review server-side validation code and test state transitions with automated tests., Review development artefacts and tests for validation logic and confirm error handling prevents submission of incomplete drafts. | Pending |
| REQ-006 | Timesheet submission workflow that records submiss… | Approval Workflow / Audit | High | THR-001, THR-003, THR-004 +7 | [NIST] AU-2, [OWASP] ASVS 5.2, [ISO27001] A.12.4.1 | Critical | Attempt to alter a submitted timesheet via UI and API; review server-side checks and database constraints ensuring immutability., Review audit logs for submission events and timestamps; verify logs are tamper-evident and properly correlated to submission records. | Pending |
| REQ-007 | Managers and assigned delegates can approve or rej… | Approval Workflow / Audit | High | THR-001, THR-003, THR-004 +7 | None | Medium | Manual Review | Pending |
| REQ-008 | Manager delegation capabilities: assign delegates … | Delegation / Authorization | High | THR-001, THR-005, THR-006 +7 | [NIST] AC-05, [OWASP] ASVS 2.5, [ISO27001] A.6.1.2 | Critical | Inspect delegation registry and policy documents, and confirm notifications are issued on changes., Create delegated roles, verify automatic expiry, execute revocation and confirm notifications and audit entries are generated. | Pending |
| REQ-009 | Holiday and leave request management: request holi… | Leave Management / Data Management | Medium | THR-001, THR-003, THR-004 +7 | [ISO27001] A.7.2.2, [NIST] AC-02, [OWASP] ASVS 5.1 | High | Examine account attributes for leave balance fields, review approval logs, and confirm state transitions require manager action., Review HR integration points, test leave request workflows and manager approvals, and verify PII protections for leave balances. | Pending |
| REQ-010 | Public holiday preload and automatic application t… | Configuration / Leave Management | Low | THR-001, THR-002, THR-003 +7 | [ISO27001] A.12.1.1, [NIST] CM-2, [OWASP] ASVS 5.1 | High | Review documentation, inspect configuration change logs, and verify that holiday preload processes are followed and auditable., Inspect configuration baselines and version history for holiday data and test rollback and update processes. | Pending |
| REQ-011 | Business rules engine to configure workweek, worki… | Business Rules / Data Validation | Medium | THR-003, THR-007, THR-008 +6 | [OWASP] ASVS 5.3, [NIST] AC-06, [ISO27001] A.14.2.5 | Critical | Test rule configuration changes, attempt to submit timesheets violating rules, and review server-side enforcement in logs and code., Review role permissions for configuration actions and validate that non-admin users cannot alter business rules. | Pending |
| REQ-012 | Email notifications for timesheet submission remin… | Notifications / Communications | Low | THR-001, THR-003, THR-004 +7 | [NIST] SI-4, [OWASP] ASVS 14.1, [ISO27001] A.10.1.1 | High | Audit email templates for sensitive content, test that emails contain minimal data and links require authentication to view details., Inspect email transport configuration for TLS, review encryption policy for stored notifications, and test interception resistance. | Pending |
| REQ-013 | Reporting: generate weekly, monthly, and custom re… | Reporting / Analytics | Medium | THR-001, THR-003, THR-008 +3 | [NIST] AC-03, [OWASP] ASVS 10.1, [ISO27001] A.9.4.1 | Critical | Test report access for various roles, attempt to access others’ reports, and review enforcement logic in reporting services., Review access control checks in reporting code and attempt to retrieve reports beyond assigned scope. | Pending |
| REQ-014 | Comprehensive audit logging capturing creation/upd… | Audit & Compliance | High | THR-001, THR-003, THR-005 +7 | [NIST] SI-4, [OWASP] ASVS 14.1, [ISO27001] A.10.1.1 | High | Audit email templates for sensitive content, test that emails contain minimal data and links require authentication to view details., Inspect email transport configuration for TLS, review encryption policy for stored notifications, and test interception resistance. | Pending |
| REQ-015 | Administrator capabilities to configure system set… | Administration / Governance | High | THR-001, THR-003, THR-006 +7 | [ISO27001] A.12.1.1, [NIST] CM-2, [OWASP] ASVS 5.1 | High | Review documentation, inspect configuration change logs, and verify that holiday preload processes are followed and auditable., Inspect configuration baselines and version history for holiday data and test rollback and update processes. | Pending |
| REQ-016 | Responsive UI supporting desktop, tablet, and mobi… | UI/UX / Accessibility | Low | None | [OWASP] ASVS 14.2, [NIST] PL-8, [ISO27001] A.14.2.1 | Medium | Review architecture documents for accessibility considerations and test with assistive technologies., Perform WCAG conformance testing, accessibility audits, and review UI designs for privacy exposures. | Pending |
| REQ-017 | Enforce data access restrictions based on team hie… | Authorization / Data Access Control | High | THR-001, THR-002, THR-003 +7 | [NIST] AC-06, [ISO27001] A.9.4.1, [OWASP] ASVS 10.1 | Critical | Audit role assignments and permissions, perform privilege escalation tests, and validate enforcement of team-based filters., Test attribute-based access control decisions in diverse scenarios and review implementation for gaps. | Pending |
| REQ-018 | Data retention, encryption at rest and in transit,… | Data Protection / Integration | High | THR-001, THR-003, THR-005 +7 | [NIST] MP-6, [ISO27001] A.8.3.3, [OWASP] ASVS 14.1 | Critical | Review classification rules, inspect encryption controls, and test secure export workflows to payroll/HR., Inspect encryption configurations, test secure export endpoints, and verify audit trails of export operations. | Pending |
Total Requirements Tracked: 18
Detailed Requirement Mappings
The following section provides detailed traceability for each requirement:
REQ-001: Role-based access control with Employee, Manager, Delegate, and Administrator roles
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-002: Session fixation or manipulation of client-side tokens (JWT tampering) leading t…
- THR-008: Broken access control or misapplied team hierarchy rules cause the API to return…
- THR-009: Administrator (or admin API credential) compromise permits system-wide configura…
- THR-010: Volumetric or application-layer DDoS against the CDN/WAF or API gateway causes s…
- …and 5 more threats
Security Controls:
- [NIST] AC-02: [NIST] The information system manages information system accounts, including establishi…
- [ISO27001] A.9.1.2: [ISO27001] Users shall only be provided with access to the network and network services tha…
- [OWASP] ASVS 2.1: [OWASP] Verify that role-based access control is implemented and enforced server-side.
Verification: Code review of authorization checks, automated tests simulating role-based access attempts, and penetration testing for role escalation vulnerabilities., Review account management procedures, inspect role assignment workflows, and test create/modify/disable/delete operations for each role; verify role enforcement in code and access control lists., Audit role-to-permission mappings, perform access control tests (positive and negative) for each role, and verify that unauthorized actions are blocked.
Priority: Critical | Status: Pending
REQ-002: Integrate with Azure SSO for authentication and support for enterprise identity (optionally enforce …
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-013: Stored or reflected XSS in the SPA exposes authentication cookies, tokens, or vi…
- THR-015: Manager or delegate claims they did not approve/reject a timesheet because audit…
- THR-017: Misconfiguration or unauthorized modification of business rules (e.g., min/max h…
Security Controls:
- [OWASP] ASVS 2.3: [OWASP] Verify correct implementation of federated authentication (SAML, OAuth2/OIDC) an…
- [NIST] IA-08: [NIST] The information system supports organizational users leveraging federated identi…
- [ISO27001] A.9.4.2: [ISO27001] Where required by the business, users shall be provided with a secure log-on pro…
Verification: Validate configuration against Azure AD metadata, test sign-on flows for multiple scenarios (fresh login, SSO, logout), and review IdP trust settings., Review secure logon procedure documentation, test SSO flows for MFA and session handling, and confirm configuration meets organizational security requirements., Review integration code/configuration, verify token validation logic, test with malformed tokens and revoked credentials, and perform federated auth flow penetration testing.
Priority: Critical | Status: Pending
REQ-003: User management and team hierarchy mapping to assign managers, team members, and delegate relationsh…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- THR-008: Broken access control or misapplied team hierarchy rules cause the API to return…
- …and 5 more threats
Security Controls:
- [NIST] AC-02: [NIST] The information system manages information system accounts, including establishi…
- [ISO27001] A.9.2.2: [ISO27001] The allocation and use of privileges shall be restricted and controlled. A forma…
- [OWASP] ASVS 2.5: [OWASP] Verify that user account management functions (create, update, disable, delete) …
Verification: Review provisioning workflow documentation, sample user profiles for correct team/manager attributes, and examine periodic access review records., Code and configuration review of account management APIs, functional tests for reassigning managers/delegates, and logs verifying change history., Audit provisioning logs, test automated synchronization against HR records, and review the process for creating/updating hierarchical relationships.
Priority: Critical | Status: Pending
REQ-004: Daily and weekly timesheet entry supporting multiple projects/tasks and project/task codes
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- …and 5 more threats
Security Controls:
- [NIST] SI-12: [NIST] The information system validates the accuracy and integrity of data inputs and d…
- [OWASP] ASVS 5.1: [OWASP] Verify business logic functions, including multi-step workflows and data correct…
- [NIST] AU-12: [NIST] The system associates user identities with actions, ensuring timesheet entries c…
Verification: Functional testing of timesheet workflows, review test coverage for multiple projects/tasks, and validate business rule enforcement during entry., Inspect logs and entries to confirm user attribution fields are recorded and cannot be altered by normal users., Run automated input validation tests, review validation code, and attempt injection and malformed input tests against timesheet entry endpoints.
Priority: Critical | Status: Pending
REQ-005: Save draft timesheets locally/server-side and prevent submission until all required fields are compl…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- THR-010: Volumetric or application-layer DDoS against the CDN/WAF or API gateway causes s…
- …and 5 more threats
Security Controls:
- [OWASP] ASVS 5.3: [OWASP] Verify that input validation and business rule enforcement prevents invalid stat…
- [NIST] SI-10: [NIST] The application checks and validates input data for completeness and correctness…
- [ISO27001] A.14.2.5: [ISO27001] Security requirements for applications including validation and error handling s…
Verification: Attempt to submit incomplete drafts via API, review server-side validation code and test state transitions with automated tests., Review development artefacts and tests for validation logic and confirm error handling prevents submission of incomplete drafts., Review validation rules, attempt invalid submissions, and confirm server rejects submissions until fields are complete.
Priority: Critical | Status: Pending
REQ-006: Timesheet submission workflow that records submission timestamp and marks timesheets read-only after…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- …and 5 more threats
Security Controls:
- [NIST] AU-2: [NIST] The information system determines which events (such as submission) are to be au…
- [OWASP] ASVS 5.2: [OWASP] Verify that state transitions are enforced server-side and that submitted record…
- [ISO27001] A.12.4.1: [ISO27001] Event logs recording user activities and timestamps shall be maintained to suppo…
Verification: Attempt to alter a submitted timesheet via UI and API; review server-side checks and database constraints ensuring immutability., Review audit logs for submission events and timestamps; verify logs are tamper-evident and properly correlated to submission records., Review logging configuration, confirm logs include submission events/timestamps, and test retention/archival processes.
Priority: Critical | Status: Pending
REQ-007: Managers and assigned delegates can approve or reject timesheets with mandatory comment field for re…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- …and 5 more threats
Verification: Manual Review
Priority: Medium | Status: Pending
REQ-008: Manager delegation capabilities: assign delegates with start/end dates, permission scope, notificati…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-011: API abuse or lack of rate limiting causes queue/backlog storm (notification/repo…
- THR-012: Attackers send spoofed emails resembling system notifications (approval requests…
- …and 5 more threats
Security Controls:
- [NIST] AC-05: [NIST] The organization separates duties of individuals as necessary, and implements de…
- [OWASP] ASVS 2.5: [OWASP] Ensure that delegation and temporary role assignments are time-bound and auditab…
- [ISO27001] A.6.1.2: [ISO27001] Conflicts of interest are reduced by segregating duties and defining responsibil…
Verification: Inspect delegation registry and policy documents, and confirm notifications are issued on changes., Create delegated roles, verify automatic expiry, execute revocation and confirm notifications and audit entries are generated., Review delegation records, test enforcement of scope and time boundaries, and perform conflict-of-interest checks.
Priority: Critical | Status: Pending
REQ-009: Holiday and leave request management: request holidays via timesheet or dedicated interface, track l…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- …and 5 more threats
Security Controls:
- [ISO27001] A.7.2.2: [ISO27001] Employees should be made aware of information security responsibilities; HR proc…
- [NIST] AC-02: [NIST] The information system manages accounts including attributes; systems supporting…
- [OWASP] ASVS 5.1: [OWASP] Verify business processes like leave requests and balance calculations are imple…
Verification: Examine account attributes for leave balance fields, review approval logs, and confirm state transitions require manager action., Review HR integration points, test leave request workflows and manager approvals, and verify PII protections for leave balances., Functional tests of leave balance computations, attempts to bypass approvals, and verify audit trails for approvals.
Priority: High | Status: Pending
REQ-010: Public holiday preload and automatic application to relevant timesheet days (configurable by region)
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-002: Session fixation or manipulation of client-side tokens (JWT tampering) leading t…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- …and 5 more threats
Security Controls:
- [ISO27001] A.12.1.1: [ISO27001] Operating procedures should be documented; application configuration (like publi…
- [NIST] CM-2: [NIST] Establish and maintain baseline configurations for information systems including…
- [OWASP] ASVS 5.1: [OWASP] Verify system-provided data and configurable presets (e.g., public holidays) are…
Verification: Review documentation, inspect configuration change logs, and verify that holiday preload processes are followed and auditable., Inspect configuration baselines and version history for holiday data and test rollback and update processes., Attempt unauthorized modification of holiday data, review access controls, and verify integrity checks for datasets.
Priority: High | Status: Pending
REQ-011: Business rules engine to configure workweek, working patterns, and enforce configurable minimum/maxi…
Related Threats:
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- THR-008: Broken access control or misapplied team hierarchy rules cause the API to return…
- THR-009: Administrator (or admin API credential) compromise permits system-wide configura…
- THR-017: Misconfiguration or unauthorized modification of business rules (e.g., min/max h…
- …and 4 more threats
Security Controls:
- [OWASP] ASVS 5.3: [OWASP] Verify business rule enforcement (configurable policies like workweek, min/max h…
- [NIST] AC-06: [NIST] The organization employs the concept of least privilege, ensuring users are gran…
- [ISO27001] A.14.2.5: [ISO27001] Security requirements for applications including enforcement of business rules a…
Verification: Test rule configuration changes, attempt to submit timesheets violating rules, and review server-side enforcement in logs and code., Review role permissions for configuration actions and validate that non-admin users cannot alter business rules., Review secure development artefacts and test suites for business rule enforcement coverage.
Priority: Critical | Status: Pending
REQ-012: Email notifications for timesheet submission reminders, pending approvals, approval/rejection confir…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-004: An attacker modifies API requests (parameter tampering) to set approval fields (…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- …and 5 more threats
Security Controls:
- [NIST] SI-4: [NIST] Implement mechanisms to monitor system notifications and ensure integrity of mes…
- [OWASP] ASVS 14.1: [OWASP] Ensure sensitive data transmitted via notifications (email) is protected and min…
- [ISO27001] A.10.1.1: [ISO27001] Use cryptographic controls to protect the confidentiality, integrity and availab…
Verification: Audit email templates for sensitive content, test that emails contain minimal data and links require authentication to view details., Inspect email transport configuration for TLS, review encryption policy for stored notifications, and test interception resistance., Review notification logs, monitor alerting, and test end-to-end notification delivery and error handling.
Priority: High | Status: Pending
REQ-013: Reporting: generate weekly, monthly, and custom reports for employees and managers with export capab…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-008: Broken access control or misapplied team hierarchy rules cause the API to return…
- THR-016: A delegate uses delegated permissions beyond the defined scope or after the dele…
- THR-019: An attacker modifies delegation records (direct DB write or API tampering) to ma…
- …and 1 more threats
Security Controls:
- [NIST] AC-03: [NIST] The system enforces approved authorizations for logical access to information an…
- [OWASP] ASVS 10.1: [OWASP] Verify that access control is applied to business functions such as report gener…
- [ISO27001] A.9.4.1: [ISO27001] Access to information and application system functions should be restricted in a…
Verification: Test report access for various roles, attempt to access others’ reports, and review enforcement logic in reporting services., Review access control checks in reporting code and attempt to retrieve reports beyond assigned scope., Audit report access policies, review permission enforcement, and test enforcement across report types.
Priority: Critical | Status: Pending
REQ-014: Comprehensive audit logging capturing creation/updates of timesheets, submissions, approvals/rejecti…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- THR-009: Administrator (or admin API credential) compromise permits system-wide configura…
- …and 5 more threats
Security Controls:
- [NIST] SI-4: [NIST] Implement mechanisms to monitor system notifications and ensure integrity of mes…
- [OWASP] ASVS 14.1: [OWASP] Ensure sensitive data transmitted via notifications (email) is protected and min…
- [ISO27001] A.10.1.1: [ISO27001] Use cryptographic controls to protect the confidentiality, integrity and availab…
Verification: Audit email templates for sensitive content, test that emails contain minimal data and links require authentication to view details., Inspect email transport configuration for TLS, review encryption policy for stored notifications, and test interception resistance., Review notification logs, monitor alerting, and test end-to-end notification delivery and error handling.
Priority: High | Status: Pending
REQ-015: Administrator capabilities to configure system settings, working patterns, public holidays, manage u…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- THR-009: Administrator (or admin API credential) compromise permits system-wide configura…
- …and 5 more threats
Security Controls:
- [ISO27001] A.12.1.1: [ISO27001] Operating procedures should be documented; application configuration (like publi…
- [NIST] CM-2: [NIST] Establish and maintain baseline configurations for information systems including…
- [OWASP] ASVS 5.1: [OWASP] Verify system-provided data and configurable presets (e.g., public holidays) are…
Verification: Review documentation, inspect configuration change logs, and verify that holiday preload processes are followed and auditable., Inspect configuration baselines and version history for holiday data and test rollback and update processes., Attempt unauthorized modification of holiday data, review access controls, and verify integrity checks for datasets.
Priority: High | Status: Pending
REQ-016: Responsive UI supporting desktop, tablet, and mobile with WCAG accessibility compliance
Security Controls:
- [OWASP] ASVS 14.2: [OWASP] Verify that privacy and accessibility considerations are addressed in applicatio…
- [NIST] PL-8: [NIST] Consider accessibility and usability as part of secure system architecture and d…
- [ISO27001] A.14.2.1: [ISO27001] Security and quality requirements for systems (including usability and accessibi…
Verification: Review architecture documents for accessibility considerations and test with assistive technologies., Perform WCAG conformance testing, accessibility audits, and review UI designs for privacy exposures., Review requirement documents, test plans, and evidence of WCAG testing and remediation activities.
Priority: Medium | Status: Pending
REQ-017: Enforce data access restrictions based on team hierarchy and least-privilege model (managers see the…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-002: Session fixation or manipulation of client-side tokens (JWT tampering) leading t…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- …and 5 more threats
Security Controls:
- [NIST] AC-06: [NIST] The organization employs the concept of least privilege, ensuring users are gran…
- [ISO27001] A.9.4.1: [ISO27001] Access to information and application system functions should be restricted in a…
- [OWASP] ASVS 10.1: [OWASP] Verify access control is applied to business functions and data based on roles a…
Verification: Audit role assignments and permissions, perform privilege escalation tests, and validate enforcement of team-based filters., Test attribute-based access control decisions in diverse scenarios and review implementation for gaps., Review policy and enforcement mechanisms, test cross-team access attempts, and confirm access logs reflect restrictions.
Priority: Critical | Status: Pending
REQ-018: Data retention, encryption at rest and in transit, and export capabilities to satisfy compliance and…
Related Threats:
- THR-001: An attacker obtains or reuses Azure AD access/refresh tokens (via phishing, toke…
- THR-003: A malicious user manipulates client-side data (e.g., via browser devtools, inter…
- THR-005: Insufficient or modifiable audit logging allows users (or attackers) to deny act…
- THR-006: Sensitive timesheet or personnel data is leaked via email notifications (e.g., d…
- THR-007: Data stored without proper encryption or network isolation is exposed via cloud …
- …and 5 more threats
Security Controls:
- [NIST] MP-6: [NIST] Protect and sanitize media containing sensitive information prior to disposal; r…
- [ISO27001] A.8.3.3: [ISO27001] Information shall be handled in accordance with its classification including ret…
- [OWASP] ASVS 14.1: [OWASP] Verify that sensitive data is protected at rest and in transit using appropriate…
Verification: Review classification rules, inspect encryption controls, and test secure export workflows to payroll/HR., Inspect encryption configurations, test secure export endpoints, and verify audit trails of export operations., Review retention policies, confirm automated purging processes, and verify proper sanitization/destruction procedures.
Priority: Critical | Status: Pending
Appendix E: References
End of Report - Generated by Security Requirements Analysis System v2.0 Generated: 2025-11-20 11:21:45